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. Os seguintes tipos de recursos são suportados:

    • pkg: usado para instalar ou remover pacotes do Linux e do Windows
    • repository: usado para especificar de quais pacotes de software de repositório podem ser instalados
    • exec: usado para ativar a execução de um script ad hoc shell (/bin/sh) ou PowerShell.
    • file: usado para gerenciar arquivos no sistema

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 Console do Google Cloud ao criar uma atribuição de política de SO.

  • Exemplo 1: instala um pacote.
  • Exemplo 2: executa um script.
  • Exemplo 3: especifica um repositório de download e instala pacotes desse repositório.
  • Exemplo 4: 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 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

Exemplo 4

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 do 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 usando famílias do SO e incluir ou excluir rótulos. É possível selecionar uma combinação das seguintes opções:

    • Famílias de SO: especifica os sistemas operacionais de destino aplicáveis à política de SO. 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:

    • Família 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