Política do SO e atribuição de política do SO

Uma política do SO é um arquivo que contém a configuração declarativa para recursos do SO, como pacotes, repositórios, arquivos ou recursos personalizados definidos por scripts. Para mais informações, consulte a definição de recursos para OSPolicy.

Uma atribuição de política de SO é um recurso de API usado pelo VM Manager para aplicar políticas de SO a VMs. Para saber mais, consulte a definição de recursos para OSPolicyAssignment.

Política de SO

Uma política de SO é um arquivo JSON ou YAML que tem três seções:

  • modo de cada campo. O comportamento da política. Os dois modos a seguir estão disponíveis:

    • Validation: para este modo, a política verifica se os recursos estão no estado pretendido, mas não realizam nenhuma ação.
    • Enforcement: nesse modo, a política verifica se os recursos estão no estado desejado e, se não estiverem, executa as ações necessárias para trazê-los para esse estado.

    Para ambos os modos, o VM Manager informa a conformidade com a política do SO e os recursos associados.

  • Grupos de recursos. O nome e a versão do sistema operacional a que as especificações de recursos associadas se aplicam. Por exemplo, é possível definir uma única política para instalar ou implantar um agente em diferentes distribuições e versões de sistemas operacionais.

  • Recursos. As especificações necessárias para que a VM atinja a configuração pretendida. É possível especificar no máximo 10 IDs de recursos em cada grupo. Os seguintes tipos de recursos são suportados:

Exemplo de políticas do SO

Os exemplos a seguir mostram como criar políticas de SO. É possível fazer upload dessas políticas de SO para o Cloud de Confiance console ao criar uma atribuição de política de SO.

  • Exemplo 1: instala um pacote.
  • Exemplo 2: executa um script.
  • Exemplo 3: executa um script armazenado em um bucket do Cloud Storage e copia o arquivo de saída para um bucket do Cloud Storage.
  • Exemplo 4: especifica um repositório de download e instala pacotes desse repositório.
  • Exemplo 5: configura a verificação de comparativo de mercado do CIS em VMs que executam o Container-Optimized OS (COS). Para mais informações sobre como usar a política do SO para a verificação de comparativo de mercado do CIS, consulte Automatizar a ativação e a verificação do status de conformidade do CIS.

Para ver uma lista completa das políticas de SO de amostra que podem ser aplicadas no seu ambiente, consulte o repositório GoogleCloudPlatform/osconfig do GitHub.

Exemplo 1

Crie uma política do SO que instale um arquivo MSI do Windows transferido de um bucket do Cloud Storage.

# An OS policy to install a Windows MSI downloaded from a Google Cloud Storage bucket.
id: install-msi-policy
mode: ENFORCEMENT
resourceGroups:
  - resources:
      - id: install-msi
        pkg:
          desiredState: INSTALLED
          msi:
            source:
              gcs:
                bucket: my-bucket
                object: my-app.msi
                generation: 1619136883923956

Exemplo 2

Crie uma política de SO que verifique se o servidor da Web Apache está em execução nas VMs do Linux.

# An OS policy that ensures Apache web server is running on Linux OSes.
id: apache-always-up-policy
mode: ENFORCEMENT
resourceGroups:
  - resources:
      id: ensure-apache-is-up
      exec:
        validate:
          interpreter: SHELL
          # If Apache web server is already running, return an exit code 100 to indicate
          # that exec resource is already in desired state. In this scenario,
          # the `enforce` step will not be run.
          # Otherwise return an exit code of 101 to indicate that exec resource is not in
          # desired state. In this scenario, the `enforce` step will be run.
          script: if systemctl is-active --quiet httpd; then exit 100; else exit 101; fi
        enforce:
          interpreter: SHELL
          # Start Apache web server and return an exit code of 100 to indicate that the
          # resource is now in its desired state.
          script: systemctl start httpd && exit 100

Exemplo 3

Crie uma política de SO que verifique se o servidor da Web Apache está em execução nas VMs do Linux. Neste exemplo, o script apache-validate.sh é armazenado em um bucket do Cloud Storage. Para copiar a saída para um bucket do Cloud Storage, o script apache-enforce.sh precisa incluir um comando semelhante a este:

      gcsutil cp my-exec-output-file gs://my-gcs-bucket
      

# An OS policy that ensures Apache web server is running on Linux OSes.
id: gcs-test-apache-always-up-policy
mode: ENFORCEMENT
resourceGroups:
  - resources:
      id: ensure-apache-is-up
      exec:
        validate:
          interpreter: SHELL
          # If Apache web server is already running, return an exit code 100 to indicate
          # that exec resource is already in desired state. In this scenario,
          # the enforce step will not be run.
          # Otherwise return an exit code of 101 to indicate that exec resource is not in
          # desired state. In this scenario, the enforce step will be run.
          file:
            gcs:
              bucket: my-gcs-bucket
              object: apache-validate.sh
              generation: 1726747503303299
        enforce:
          interpreter: SHELL
          # Start Apache web server and return an exit code of 100 to indicate that the
          # resource is now in its desired state.
          file:
            gcs:
              bucket: my-gcs-bucket
              object: apache-enforce.sh
              generation: 1726747503250884

Exemplo 4

Crie uma política de SO que instale os agentes do Google Cloud Observability nas VMs do CentOS.

id: cloudops-policy
mode: ENFORCEMENT
resourceGroups:
  - resources:
      - id: add-repo
        repository:
          yum:
            id: google-cloud-ops-agent
            displayName: Google Cloud Ops Agent Repository
            baseUrl: https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el7-x86_64-all
            gpgKeys:
              - https://packages.cloud.google.com/yum/doc/yum-key.gpg
              - https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
      - id: install-pkg
        pkg:
          desiredState: INSTALLED
          yum:
            name: google-cloud-ops-agent
      - id: exec-script
        exec:
          validate:
            script: |-
              if [[ $(rpm --query --queryformat '%{VERSION}
              ' google-cloud-ops-agent) == '1.0.2' ]]; then exit 100; else exit 101; fi
            interpreter: SHELL
          enforce:
            script:
              sudo yum remove -y google-cloud-ops-agent || true; sudo yum install
              -y 'google-cloud-ops-agent-1.0.2*' && exit 100
            interpreter: SHELL
      - id: ensure-agent-running
        exec:
          validate:
            script:
              if (ps aux | grep 'opt[/].*google-cloud-ops-agent.*bin/'); then exit
              100; else exit 101; fi
            interpreter: SHELL
          enforce:
            script: sudo systemctl start google-cloud-ops-agent.target && exit 100
            interpreter: SHELL

Example 5

Configura a verificação periódica de CIS de nível 1 com o período padrão de uma vez por dia.

# An OS policy to check CIS level 1 compliance once a day.
id: ensure-cis-level1-compliance-once-a-day-policy
mode: ENFORCEMENT
resourceGroups:
  - resources:
      id: ensure-cis-level1-compliance-once-a-day
      exec:
        validate:
          interpreter: SHELL
          # If cis-compliance-scanner.service is active, return an exit code
          # 100 to indicate that the instance is in compliant state.
          # Otherwise, return an exit code of 101 to run `enforce` step.
          script: |-
            is_active=$(systemctl is-active cis-compliance-scanner.timer)
            result=$(systemctl show -p Result --value cis-compliance-scanner.service)

            if [ "$is_active" == "active" ] && [ "$result" == "success" ]; then
              exit 100;
            else
              exit 101;
            fi
        enforce:
          interpreter: SHELL
          # COS 97 images are by-default CIS Level 1 compliant and there is no
          # additional configuration needed. However, if certain changes
          # cause non-compliance because of the workload on the instance, this
          # section can be used to automate to make fixes. For example, the
          # workload might generate a file that does not comply with the
          # recommended file permissions.
          # Return an exit code of 100 to indicate that the desired changes
          # successfully applied.
          script: |-
            # optional <your code>
            # Check the compliance of the instance once a day.
            systemctl start cis-compliance-scanner.timer && exit 100

Atribuição de política de SO

Uma atribuição de política do SO tem as seguintes seções:

  • Políticas de SO. Uma ou mais políticas do SO que você quer aplicar à VM; Para fazer o download ou criar uma política, consulte as Políticas do SO.

  • VMs de destino. Um conjunto de VMs em uma única zona à qual você quer aplicar a política. Em uma zona, é possível limitar ou restringir as VMs especificando os nomes dos SOs e incluindo ou excluindo rótulos. É possível selecionar uma combinação das seguintes opções:

    • Zona: especifica a zona do Cloud de Confiance by S3NS em que você quer implantar a atribuição de política do SO.
    • Nome e versão do SO: especifica o nome abreviado e a versão do sistema operacional de destino a que a política de SO se aplica.

    Para filtrar VMs com base no sistema operacional, use qualquer um dos seguintes nomes abreviados nos arquivos YAML da política de SO:

    Nome completo Nome curto
    CentOS centos
    Container-Optimized OS (COS) cos
    Debian debian
    openSUSE Leap opensuse-leap
    Oracle Linux ol
    Red Hat Enterprise Linux (RHEL) rhel
    Rocky Linux rocky
    SUSE Linux Enterprise Server (SLES) sles
    Ubuntu ubuntu
    Windows Server windows

    Para ver uma lista completa de sistemas operacionais e versões compatíveis com políticas de SO, consulte Detalhes do sistema operacional.

    • Incluir conjunto: especifica as VMs a que a política do SO se aplica com base nos rótulos da VM ou do sistema.
    • Excluir conjunto: especifica as VMs que a política de SO precisa ignorar com base nos rótulos da VM ou do sistema.

    Para conjuntos de inclusão e exclusão de rótulos, um único rótulo de string será aceito se corresponder à convenção de nomenclatura usada pelo sistema. No entanto, a maioria dos rótulos é especificada em pares key:value. Para mais informações sobre rótulos, consulte Como rotular recursos.

    Por exemplo, é possível selecionar todas as VMs do Ubuntu no ambiente de teste e excluir aquelas que executam o Google Kubernetes Engine. Basta especificar o seguinte:

    • Nome curto do SO: ubuntu
    • Incluir: env:test, env:staging
    • Excluir: goog-gke-node

  • Uma taxa de lançamento. Especifica o ritmo em que as políticas do sistema operacional serão aplicadas às VMs. As políticas do SO são lançadas gradualmente para permitir que você acompanhe a integridade do sistema e faça modificações se as atualizações causarem regressões no seu ambiente. Um plano de lançamento tem os seguintes componentes:

    • Tamanho da onda (orçamento de interrupção): o número fixo ou a porcentagem de VMs que podem passar por um lançamento de uma só vez. Isso significa que, a qualquer momento do lançamento, apenas um número específico de VMs é segmentado.
    • Tempo de espera: o tempo entre o momento em que o serviço aplica políticas à VM e quando uma VM é removida do limite de interrupção. Por exemplo, um tempo de espera de 15 minutos significa que o processo de lançamento precisa aguardar 15 minutos após aplicar as políticas a uma VM antes de removê-la do limite de interrupção e o lançamento pode continuar. O tempo de espera ajuda a controlar a velocidade de um lançamento e também permite identificar e resolver possíveis problemas com antecedência. Selecione um período longo o suficiente para monitorar o status dos lançamentos.

    Por exemplo, se você definir um destino de 10 VMs, definir o limite de interrupção para 20% e definir um tempo de preparação de 15 minutos, será preciso programar a atualização de apenas duas VMs a qualquer momento. Depois que cada VM é atualizada, 15 minutos precisam ser removidos para que ela seja removida do limite de interrupção e outra VM seja adicionada ao lançamento.

    Para mais informações sobre lançamentos, consulte Lançamentos.

Exemplo de atribuição de políticas do SO

Os exemplos a seguir mostram como criar atribuições de política do SO. Você pode usar esses exemplos para criar atribuições de política do SO na Google Cloud CLI ou na API OS Config.

  • Exemplo 1: instala um pacote.
  • Exemplo 2: executa um script.
  • Exemplo 3: especifica um repositório de download e instala pacotes desse repositório.

Para uma lista de atribuições de política de amostra do SO que podem ser aplicadas no seu ambiente, consulte o repositório GoogleCloudPlatform/osconfig do GitHub.

Exemplo 1

Crie uma atribuição de política de SO que instale um arquivo MSI do Windows transferido por download de um bucket do Cloud Storage.

# An OS policy assignment to install a Windows MSI downloaded from a Google Cloud Storage bucket
# on all VMs running Windows Server OS.
osPolicies:
  - id: install-msi-policy
    mode: ENFORCEMENT
    resourceGroups:
      - resources:
          - id: install-msi
            pkg:
              desiredState: INSTALLED
              msi:
                source:
                  gcs:
                    bucket: my-bucket
                    object: my-app.msi
                    generation: 1619136883923956
instanceFilter:
  inventories:
    - osShortName: windows
rollout:
  disruptionBudget:
    fixed: 10
  minWaitDuration: 300s

Exemplo 2

Crie uma atribuição de política do SO que verifique se o servidor da Web Apache está em execução em todas as VMs do Linux.

# An OS policy assignment that ensures Apache web server is running on Linux OSes.
# The assignment is applied only to those VMs that have the label `type:webserver` assigned to them.
osPolicies:
  - id: apache-always-up-policy
    mode: ENFORCEMENT
    resourceGroups:
      - resources:
          id: ensure-apache-is-up
          exec:
            validate:
              interpreter: SHELL
              # If Apache web server is already running, return an exit code 100 to indicate
              # that exec resource is already in desired state. In this scenario,
              # the `enforce` step will not be run.
              # Otherwise return an exit code of 101 to indicate that exec resource is not in
              # desired state. In this scenario, the `enforce` step will be run.
              script: if systemctl is-active --quiet httpd; then exit 100; else exit 101; fi
            enforce:
              interpreter: SHELL
              # Start Apache web server and return an exit code of 100 to indicate that the
              # resource is now in its desired state.
              script: systemctl start httpd && exit 100
instanceFilter:
  inclusionLabels:
    - labels:
        type: webserver
rollout:
  disruptionBudget:
    fixed: 10
  minWaitDuration: 300s

Exemplo 3

Cria uma atribuição de política de SO que instale os agentes do Google Cloud Observability nas VMs do CentOS.

# An OS policy assignment that ensures google-cloud-ops-agent is running on all Centos VMs in the project
osPolicies:
  - id: cloudops-policy
    mode: ENFORCEMENT
    resourceGroups:
        resources:
          - id: add-repo
            repository:
              yum:
                id: google-cloud-ops-agent
                displayName: Google Cloud Ops Agent Repository
                baseUrl: https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el7-x86_64-all
                gpgKeys:
                  - https://packages.cloud.google.com/yum/doc/yum-key.gpg
                  - https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
          - id: install-pkg
            pkg:
              desiredState: INSTALLED
              yum:
                name: google-cloud-ops-agent
          - id: exec-script
            exec:
              validate:
                script: |-
                  if [[ $(rpm --query --queryformat '%{VERSION}
                  ' google-cloud-ops-agent) == '1.0.2' ]]; then exit 100; else exit 101; fi
                interpreter: SHELL
              enforce:
                script:
                  sudo yum remove -y google-cloud-ops-agent || true; sudo yum install
                  -y 'google-cloud-ops-agent-1.0.2*' && exit 100
                interpreter: SHELL
          - id: ensure-agent-running
            exec:
              validate:
                script:
                  if (ps aux | grep 'opt[/].*google-cloud-ops-agent.*bin/'); then exit
                  100; else exit 101; fi
                interpreter: SHELL
              enforce:
                script: sudo systemctl start google-cloud-ops-agent.target && exit 100
                interpreter: SHELL
instanceFilter:
  inventories:
    - osShortName: centos
rollout:
  disruptionBudget:
    fixed: 10
  minWaitDuration: 300s

A seguir