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

Uma política de SO é um ficheiro que contém a configuração declarativa para recursos do SO, como pacotes, repositórios, ficheiros 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 mais informações, consulte a definição de recursos para OSPolicyAssignment.

Política de SO

Uma política de SO é um ficheiro JSON ou YAML com três secções:

  • Modo. O comportamento das políticas. Estão disponíveis os dois modos seguintes:

    • Validation: para este modo, a política verifica se os recursos estão no estado escolhido, mas não toma nenhuma medida.
    • Enforcement: para este modo, a política verifica se os recursos estão no estado escolhido e, se não estiverem, realiza as ações necessárias para os colocar nesse estado.

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

  • Grupos de recursos. O nome e a versão do sistema operativo aos quais se aplicam as especificações dos recursos associados. Por exemplo, pode definir uma única política para instalar ou implementar um agente em diferentes distribuições e versões do sistema operativo.

  • Recursos. As especificações necessárias para a VM atingir a configuração selecionada. Pode especificar um máximo de 10 IDs de recursos em cada grupo de recursos. São suportados os seguintes tipos de recursos:

Exemplos de políticas de SO

Os exemplos seguintes mostram como criar políticas de SO. Pode carregar estas políticas de SO para a Trusted Cloud consola quando 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 num contentor do Cloud Storage e copia o ficheiro de saída para um contentor do Cloud Storage.
  • Exemplo 4: especifica um repositório de transferência e instala pacotes desse repositório.
  • Exemplo 5: configura a análise comparativa da CIS em VMs que executam o SO otimizado para contentores (COS). Para mais informações sobre a utilização da política do SO para a análise de referências da CIS, consulte o artigo Automatize a ativação e a verificação do estado de conformidade com a CIS.

Para ver uma lista completa de políticas de SO de exemplo que pode aplicar no seu ambiente, consulte o repositório do GitHub GoogleCloudPlatform/osconfig.

Exemplo 1

Crie uma política de SO que instale um 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 Web Apache está em execução nas suas 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 Web Apache está em execução nas suas VMs do Linux. Neste exemplo, o script apache-validate.sh está armazenado num contentor do Cloud Storage. Para copiar a saída para um contentor do Cloud Storage, o script apache-enforce.sh tem de incluir um comando semelhante ao seguinte:

      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 agentes do Google Cloud Observability 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 análise periódica de Nível 1 da CIS com o período predefinido 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íticas do SO

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

  • Políticas de SO. Uma ou mais políticas de SO que quer aplicar à sua VM. Para transferir ou criar uma política, consulte as políticas do SO.

  • VMs de destino. Um conjunto de VMs numa única zona à qual quer aplicar a política. Numa zona, pode limitar ou restringir as VMs através de famílias de SO e incluir ou excluir etiquetas. Pode selecionar uma combinação das seguintes opções:

    • Famílias de SO: especifica os sistemas operativos de destino aos quais a política de SO se aplica. Para ver uma lista completa dos sistemas operativos e das versões que suportam as políticas de SO, consulte os detalhes do sistema operativo.
    • Include set: especifica as VMs às quais a política do SO se aplica com base nas etiquetas de VM ou do sistema.
    • Conjunto de exclusões: especifica as VMs que a política do SO deve ignorar com base nas etiquetas de VM ou do sistema.

    Para os conjuntos de etiquetas de inclusão e exclusão, é aceite uma única etiqueta de string se corresponder à convenção de nomenclatura usada pelo sistema. No entanto, a maioria das etiquetas é especificada em pares key:value. Para mais informações sobre etiquetas, consulte o artigo Etiquetar recursos.

    Por exemplo, pode selecionar todas as VMs Ubuntu no seu ambiente de teste e excluir as que estão a executar 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 ao qual as políticas do SO são aplicadas às VMs. As políticas de SO são implementadas gradualmente para lhe permitir monitorizar o estado do sistema e fazer modificações se as atualizações causarem regressões no seu ambiente. Um plano de implementação tem os seguintes componentes:

    • Tamanho da onda (orçamento de interrupção): o número fixo ou a percentagem de VMs que podem ter uma implementação ao mesmo tempo. Isto significa que, em qualquer momento da implementação, apenas um número especificado de VMs é segmentado.
    • 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 tem de 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 continuar. O tempo de espera ajuda a controlar a velocidade de uma implementação e também permite detetar e resolver potenciais problemas de implementação antecipadamente. Selecione um período suficientemente longo para monitorizar o estado das implementações.

    Por exemplo, se definir um destino de 10 VMs, definir o limite de interrupção em 20% e definir um tempo de preparação de 15 minutos, em qualquer altura, apenas 2 VMs são agendadas para atualização. Após a atualização de cada MV, têm de decorrer 15 minutos antes de a MV ser removida do limite de interrupção e de ser adicionada outra MV à implementação.

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

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

Os exemplos seguintes mostram como criar atribuições de políticas de SO. Pode usar estes exemplos para criar atribuições de políticas do SO a partir da CLI Google Cloud ou da API OS Config.

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

Para ver uma lista de exemplos de atribuições de políticas de SO que pode aplicar no seu ambiente, consulte o repositório GitHub GoogleCloudPlatform/osconfig.

Exemplo 1

Crie uma atribuição de política do SO que instale um MSI do Windows transferido a partir de um contentor 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á a ser executado em todas as suas 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 do SO que instala agentes do Google Cloud Observability em 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

O que se segue?