Política de SO e atribuição de política de 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 obter mais informações, consulte a definição de recurso 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 obter mais informações, consulte a definição de recurso para OSPolicyAssignment .

Política do sistema operacional

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

  • Modo . O comportamento político. Os dois modos a seguir estão disponíveis:

    • Validation : neste modo, a política verifica se os recursos estão no estado escolhido, mas não realiza nenhuma ação.
    • Enforcement : para este modo, a política verifica se os recursos estão no estado escolhido e, caso não estejam, executa as ações necessárias para trazê-los para esse estado escolhido.

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

  • Grupos de recursos . O nome e a versão do sistema operacional aos quais as especificações de recurso associadas se aplicam. Por exemplo, você pode 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 selecionada. Você pode especificar no máximo 10 IDs de recursos em cada grupo de recursos. Os seguintes tipos de recursos são suportados:

Exemplo de políticas de sistema operacional

Os exemplos a seguir mostram como criar políticas de sistema operacional. Você pode 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: 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 benchmark CIS em VMs que executam o Container-Optimized OS (COS). Para obter mais informações sobre como usar a política do sistema operacional para verificação de benchmark do CIS, consulte Automatizar a habilitação e a verificação do status de conformidade do CIS .

Para obter uma lista completa de exemplos de políticas de sistema operacional que você pode aplicar em seu ambiente, consulte o repositório GoogleCloudPlatform/osconfig GitHub.

Exemplo 1

Crie uma política de sistema operacional que instale um MSI do Windows baixado 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 web Apache está em execução nas suas VMs 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 web Apache está em execução nas suas VMs 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 sistema operacional que instale agentes de observabilidade do Google Cloud em VMs 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 5

Configura a verificação periódica do CIS 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 sistema operacional

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

  • Políticas de SO . Uma ou mais políticas de SO que você deseja aplicar à sua VM. Para baixar ou criar uma política, consulte Políticas de SO .

  • VMs de destino . Um conjunto de VMs em uma única zona à qual você deseja aplicar a política. Dentro de uma zona você pode limitar ou restringir VMs usando famílias de sistemas operacionais e incluir ou excluir rótulos. Você pode selecionar uma combinação das seguintes opções:

    • Famílias de SO: especifica os sistemas operacionais de destino aos quais a política de SO se aplica. Para obter uma lista completa de sistemas operacionais e versões que suportam políticas de SO, consulte Detalhes do sistema operacional .
    • Conjunto de inclusão: especifica as VMs às quais a política do sistema operacional se aplica com base em rótulos de VM ou de sistema.
    • Conjunto de exclusão: especifica as VMs que a política do sistema operacional deve ignorar com base na VM ou nos rótulos do sistema.

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

    Por exemplo, você pode selecionar todas as VMs do Ubuntu em seu ambiente de teste e excluir aquelas que executam o Google Kubernetes Engine, especificando o seguinte:

    • Família de SO: ubuntu
    • Incluir: env:test , env:staging
    • Excluir: goog-gke-node

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

    • Tamanho da onda (orçamento de interrupção): o número fixo ou porcentagem de VMs que podem passar por uma implementação de uma só vez. Isto significa que, em qualquer momento da implementação, apenas um número específico de VMs será direcionado.
    • Tempo de espera: o tempo entre o momento em que o serviço aplica políticas à VM e o momento em que uma VM é removida do limite de interrupção. Por exemplo, um tempo de espera de 15 minutos significa que o processo de implementação deve esperar 15 minutos após a aplicação das políticas a uma VM antes de poder remover a VM do limite de interrupção e a implementação poder prosseguir. O tempo de espera ajuda a controlar a velocidade de uma implementação e também permite detectar e resolver possíveis problemas de implementação antecipadamente. Selecione um tempo que seja longo o suficiente para monitorar o status de suas implementações.

    Por exemplo, se você definir uma meta de 10 VMs, definir o limite de interrupção em 20% e definir um tempo de preparação de 15 minutos, então, a qualquer momento, apenas 2 VMs serão agendadas para serem atualizadas. Após a atualização de cada VM, devem passar 15 minutos antes que a VM seja removida do limite de interrupção e outra VM seja adicionada à implementação.

    Para obter mais informações sobre implementações, consulte Implementações .

Exemplo de atribuição de política de SO

Os exemplos a seguir mostram como criar atribuições de política de SO. Você pode usar estes exemplos para criar atribuições de políticas de SO a partir da CLI do Google Cloud ou da 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 obter uma lista de exemplos de atribuições de política de sistema operacional que você pode aplicar em seu ambiente, consulte o repositório GoogleCloudPlatform/osconfig GitHub.

Exemplo 1

Crie uma atribuição de política de SO que instale um MSI do Windows baixado 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 de SO que verifique se o servidor web Apache está em execução em todas as suas VMs 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 instala agentes de observabilidade do Google Cloud em VMs 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

O que vem a seguir?