Política del SO y asignación de política del SO

Una política del SO es un archivo que contiene la configuración declarativa de los recursos de SO, como paquetes, repositorios, archivos o recursos personalizados definidos por secuencias de comandos. Para obtener más información, consulta la definición del recurso OSPolicy.

Una asignación de política del SO es un recurso de API que usa VM Manager para aplicar políticas del SO a las VM. Para obtener más información, consulta la definición del recurso de OSPolicyAssignment.

Políticas del SO

Una política del SO es un archivo JSON o YAML que tiene tres secciones:

  • Modo de cada campo. El comportamiento de la política. Se encuentran disponibles los siguientes dos modos:

    • Validation: para este modo, la política verifica si los recursos están en el estado deseado, pero no realiza ninguna acción.
    • Enforcement: para este modo, la política verifica si los recursos están en el estado deseado y, de no ser así, realiza las acciones necesarias para llevarlos a ese estado deseado.

    Para ambos modos, VM Manager informa el cumplimiento de la política del SO y los recursos asociados.

  • Grupos de recursos. El nombre y la versión del sistema operativo a los que se aplican las especificaciones de los recursos asociados. Por ejemplo, puedes definir una sola política para instalar o implementar un agente en diferentes distribuciones y versiones del sistema operativo.

  • Recursos Las especificaciones necesarias para que la VM alcance la configuración seleccionada. Se admiten los siguientes tipos de recursos:

    • pkg: se usa para instalar o quitar paquetes de Linux y Windows.
    • repository: se usa para especificar desde qué paquetes de software de repositorio se pueden instalar.
    • exec: se usa para habilitar la ejecución de una secuencia de comandos ad-hoc (/bin/sh) o PowerShell.
    • file: se usa para administrar archivos en el sistema.

Políticas del SO de ejemplo

En los siguientes ejemplos, se muestra cómo crear políticas del SO. Puedes subir estas políticas del SO a la consola de Google Cloud cuando creas una asignación de política del SO.

  • Ejemplo 1: instala un paquete.
  • Ejemplo 2: ejecuta una secuencia de comandos.
  • Ejemplo 3: especifica un repositorio de descarga y, luego, instala paquetes desde ese repositorio.
  • Ejemplo 4: Configura el análisis de comparativas de CIS en VMs que ejecutan Container-Optimized OS (COS). Si deseas obtener más información sobre el uso de la política de SO para el análisis de comparativas de CIS, consulta Automatiza la habilitación y la verificación del estado de cumplimiento de CIS.

Para obtener una lista completa de las políticas del SO de muestra que puedes aplicar en tu entorno, consulta el repositorio de GitHub GoogleCloudPlatform/osconfig.

Ejemplo 1

Crear una política del SO que instale un MSI de Windows descargado desde un bucket de Cloud Storage.

examples/OSPolicyAssignments/console/install_msi_windows_all.yaml 
# 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

Ejemplo 2

Crea una política del SO que verifique si el servidor web Apache se está ejecutando en las VM de Linux.

examples/OSPolicyAssignments/console/exec_script_linux_all.yaml 
# 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

Ejemplo 3

Crear una política del SO que instale agentes de observabilidad de Google Cloud en las VMs de CentOS.

examples/OSPolicyAssignments/console/cloudops-centos.yaml 
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

Ejemplo 4

Configura el análisis periódico de CIS en el nivel 1 con el período predeterminado de una vez al día.

examples/OSPolicyAssignments/console/CIS/cis-level1-once-a-day-policy.yaml 
# An OS policy to check CIS level 1 compliance once a day.
osPolicies:
- 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

Asignación de política del SO

Una asignación de política del SO tiene las siguientes secciones:

  • Políticas del SO. Una o más políticas del SO que deseas aplicar a la VM. Para descargar o crear una política, consulta Políticas del SO.

  • VM de destino. Un conjunto de VM dentro de una sola zona en la que deseas aplicar la política. Dentro de una zona puedes limitar o restringir las VM con las familias de SO y, además, incluir o excluir etiquetas. Puedes seleccionar una combinación de las siguientes opciones:

    • Familias de SO: especifica los sistemas operativos de destino a los que se aplica la política del SO. Para obtener una lista completa de los sistemas operativos y las versiones compatibles con las políticas del SO, consulta Detalles de los sistemas operativos.
    • Incluir conjunto: especifica las VM a las que se aplica la política del SO según las etiquetas de la VM o el sistema.
    • Excluir conjunto: especifica las VM que debe ignorar la política del SO según las etiquetas de la VM o el sistema.

    Tanto para incluir como para excluir conjuntos de etiquetas, se acepta una sola etiqueta de string si coincide con la convención de nombres que usa el sistema. Sin embargo, la mayoría de las etiquetas se especifican en pares key:value. Para obtener más información sobre las etiquetas, consulta Etiqueta recursos.

    Por ejemplo, puedes seleccionar todas las VM de Ubuntu en el entorno de prueba y excluir aquellas que se ejecutan en Google Kubernetes Engine si especificas lo siguiente:

    • Familia del SO: ubuntu
    • Incluir: env:test, env:staging
    • Excluir: goog-gke-node

  • Una tasa de lanzamiento. Especifica el ritmo en el que se aplicarán las políticas del SO a las VM. Las políticas del SO se lanzan de forma gradual para permitirte realizar un seguimiento del estado del sistema y realizar modificaciones si las actualizaciones causan regresiones en el entorno. Un plan de lanzamiento tiene los siguientes componentes:

    • Tamaño del conjunto (presupuesto de interrupción): la cantidad fija o el porcentaje de VM que pueden experimentar un lanzamiento a la vez. Esto significa que, en cualquier momento de la implementación, solo se orientan a una cantidad específica de VM.
    • Tiempo de espera: el tiempo que transcurre desde que el servicio aplica políticas a la VM hasta que esta se quita del umbral de interrupción. Por ejemplo, un tiempo de espera de 15 minutos significa que el proceso de lanzamiento debe esperar 15 minutos después de aplicar las políticas a una VM antes de que se la pueda quitar del umbral de interrupción y se pueda continuar con el lanzamiento. El tiempo de espera ayuda a controlar la velocidad del lanzamiento y también te permite detectar y resolver posibles problemas de lanzamiento de manera anticipada. Selecciona un período que sea lo suficientemente largo para supervisar el estado de los lanzamientos.

    Por ejemplo, si estableces un objetivo de 10 VM, estableces el umbral de interrupción en 20% y estableces un tiempo de preparación de 15 minutos, entonces, en cualquier momento determinado, solo se programan 2 VM para actualizarse. Después de actualizar cada VM, deben pasar 15 minutos antes de que se quite la VM del umbral de interrupción y se agregue otra VM al lanzamiento.

    Para obtener más información sobre los lanzamientos, consulta Lanzamientos.

Asignación de política del SO de ejemplo

En los siguientes ejemplos, se muestra cómo crear asignaciones de políticas del SO. Puedes usar estos ejemplos para crear asignaciones de políticas del SO desde Google Cloud CLI o la API de configuración del SO.

  • Ejemplo 1: instala un paquete.
  • Ejemplo 2: ejecuta una secuencia de comandos.
  • Ejemplo 3: especifica un repositorio de descarga y, luego, instala paquetes desde ese repositorio.

Para obtener una lista de las asignaciones de políticas del SO de muestra que puedes aplicar en tu entorno, consulta el repositorio de GitHub GoogleCloudPlatform/osconfig.

Ejemplo 1

Crea una asignación de política del SO que instale un MSI de Windows descargado desde un bucket de Cloud Storage.

examples/OSPolicyAssignments/gcloud/install_msi_windows_all.yaml 
# 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

Ejemplo 2

Crea una asignación de política del SO que verifique si el servidor web Apache se está ejecutando en todas las VM de Linux.

examples/OSPolicyAssignments/gcloud/exec_script_linux_all.yaml 
# 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

Ejemplo 3

Crea una asignación de política del SO que instale agentes de observabilidad de Google Cloud en las VMs de CentOS.

examples/OSPolicyAssignments/gcloud/cloudops-centos.yaml 
# 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

Próximos pasos