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

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

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

Política de SO

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

  • Modo. El comportamiento de la política. Están disponibles los dos modos siguientes:

    • Validation: en este modo, la política comprueba si los recursos están en el estado elegido, pero no toma ninguna medida.
    • Enforcement: en este modo, la política comprueba si los recursos se encuentran en el estado elegido y, si no es así, realiza las acciones necesarias para que alcancen ese estado.

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

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

  • Recursos: Las especificaciones necesarias para que la VM alcance la configuración seleccionada. Puedes especificar un máximo de 10 IDs de recursos en cada grupo de recursos. 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é repositorio se pueden instalar paquetes de software.
    • exec: se usa para habilitar la ejecución de una shell ad hoc (/bin/sh) o una secuencia de comandos de PowerShell.

    • file: se usa para gestionar archivos en el sistema.

      .

Ejemplos de políticas de SO

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

  • Ejemplo 1: instala un paquete.
  • Ejemplo 2: ejecuta una secuencia de comandos.
  • Ejemplo 3: ejecuta una secuencia de comandos almacenada en un segmento de Cloud Storage y copia el archivo de salida en un segmento de Cloud Storage.
  • Ejemplo 4: especifica un repositorio de descargas e instala paquetes de ese repositorio.
  • Ejemplo 5: configura el análisis de la prueba comparativa de CIS en máquinas virtuales que ejecutan Container-Optimized OS (COS). Para obtener más información sobre cómo usar la política de SO para analizar las comparativas del CIS, consulta Automatizar la habilitación y la comprobación del estado de cumplimiento del CIS.

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

Ejemplo 1

Crea una política de SO que instale un archivo MSI de Windows descargado de un segmento de 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

Ejemplo 2

Crea una política de SO que verifique si el servidor web Apache se está ejecutando en tus máquinas virtuales 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

Ejemplo 3

Crea una política de SO que verifique si el servidor web Apache se está ejecutando en tus máquinas virtuales Linux. En este ejemplo, la secuencia de comandos apache-validate.sh se almacena en un segmento de Cloud Storage. Para copiar la salida en un segmento de Cloud Storage, la secuencia de comandos apache-enforce.sh debe incluir un comando similar al siguiente:

      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

Ejemplo 4

Crea una política de SO que instale agentes de Google Cloud Observability en máquinas virtuales 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

Ejemplo 5

Configura la comprobación periódica de nivel 1 de CIS con el periodo predeterminado de una vez al día.

# 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

Asignación de política de SO

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

  • Políticas de SO. Una o varias políticas de SO que quieras aplicar a tu VM. Para descargar o crear una política, consulta Políticas de SO.

  • Máquinas virtuales de destino. Un conjunto de VMs de una sola zona a las que quieras aplicar la política. En una zona, puedes limitar o restringir las VMs mediante familias de SO e 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 de SO. Para ver una lista completa de los sistemas operativos y las versiones que admiten las políticas de SO, consulta los detalles del sistema operativo.
    • Incluir conjunto: especifica las VMs a las que se aplica la política de SO en función de las etiquetas de VM o del sistema.
    • Conjunto de exclusión: especifica las VMs que debe ignorar la política de SO en función de las etiquetas de VM o del sistema.

    En el caso de los conjuntos de etiquetas de inclusión y exclusión, se acepta una sola etiqueta de cadena si coincide con la convención de nomenclatura 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 el artículo Etiquetar recursos.

    Por ejemplo, puedes seleccionar todas las máquinas virtuales de Ubuntu de tu entorno de pruebas y excluir las que ejecutan Google Kubernetes Engine especificando lo siguiente:

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

  • Una tasa de lanzamiento. Especifica el ritmo al que se aplican las políticas del SO a las VMs. Las políticas del SO se implementan gradualmente para que puedas monitorizar el estado del sistema y hacer modificaciones si las actualizaciones provocan regresiones en tu entorno. Un plan de lanzamiento tiene los siguientes componentes:

    • Tamaño de la oleada (presupuesto de interrupción): número fijo o porcentaje de las VMs que pueden experimentar un lanzamiento a la vez. Esto significa que, en cualquier momento del lanzamiento, solo se segmenta un número específico de VMs.
    • Tiempo de espera: tiempo que transcurre entre el momento en que el servicio aplica las políticas a la VM y el momento en que se elimina la VM del umbral de interrupción. Por ejemplo, si el tiempo de espera es de 15 minutos, el proceso de lanzamiento debe esperar 15 minutos después de aplicar las políticas a una VM para poder eliminarla del umbral de interrupción y continuar con el lanzamiento. El tiempo de espera ayuda a controlar la velocidad de un lanzamiento y también te permite detectar y resolver posibles problemas de lanzamiento con antelación. Selecciona un periodo lo suficientemente largo como para monitorizar el estado de tus lanzamientos.

    Por ejemplo, si define un objetivo de 10 VMs, un umbral de interrupción del 20 % y un tiempo de estabilización de 15 minutos, en cualquier momento solo se programarán 2 VMs para que se actualicen. Después de actualizar cada VM, deben transcurrir 15 minutos antes de que se elimine del umbral de interrupción y se añada otra VM a la implementación.

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

Ejemplo de asignación de política de SO

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

  • Ejemplo 1: instala un paquete.
  • Ejemplo 2: ejecuta una secuencia de comandos.
  • Ejemplo 3: especifica un repositorio de descargas e instala paquetes de ese repositorio.

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

Ejemplo 1

Crea una asignación de política de SO que instale un archivo MSI de Windows descargado de un segmento de 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

Ejemplo 2

Crea una asignación de políticas de SO que verifique si el servidor web Apache se está ejecutando en todas tus 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

Ejemplo 3

Crea una asignación de política de SO que instala agentes de observabilidad de Google Cloud en máquinas virtuales 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

Siguientes pasos