Política de sistema operativo y asignación de política de sistema operativo

Una política de sistema operativo es un archivo que contiene la configuración declarativa para recursos del sistema operativo, como paquetes, repositorios, archivos o recursos personalizados definidos por scripts. Para obtener más información, consulte la definición de recursos para OSPolicy .

Una asignación de política de sistema operativo es un recurso API que utiliza VM Manager para aplicar políticas de sistema operativo a las máquinas virtuales. Para obtener más información, consulte la definición de recurso para OSPolicyAssignment .

política del sistema operativo

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

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

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

    Para ambos modos, VM Manager informa el cumplimiento de la política del sistema operativo y 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, puede definir una política única 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. Puede especificar un máximo de 10 ID de recursos en cada grupo de recursos. Se admiten los siguientes tipos de recursos:

    • pkg : utilizado para instalar o eliminar paquetes de Linux y Windows
    • repository : se utiliza para especificar qué paquetes de software de repositorio se pueden instalar desde
    • exec : se utiliza para habilitar la ejecución de un shell ad hoc ( /bin/sh ) o un script de PowerShell
    • file : utilizado para administrar archivos en el sistema

Ejemplos de políticas de sistema operativo

Los siguientes ejemplos muestran cómo crear políticas de sistema operativo. Puede cargar estas políticas de sistema operativo en la consola de Google Cloud al crear una asignación de política de sistema operativo.

  • Ejemplo 1: instala un paquete.
  • Ejemplo 2: ejecuta un script.
  • Ejemplo 3: ejecuta una secuencia de comandos que está almacenada en un depósito de Cloud Storage y copia el archivo de salida en un depósito de Cloud Storage.
  • Ejemplo 4: especifica un repositorio de descarga e instala paquetes desde ese repositorio.
  • Ejemplo 5: configura el análisis comparativo de CIS en máquinas virtuales que ejecutan un sistema operativo optimizado para contenedores (COS). Para obtener más información sobre el uso de la política del sistema operativo para el análisis comparativo de CIS, consulte Automatizar la habilitación y verificación del estado de cumplimiento de CIS .

Para obtener una lista completa de ejemplos de políticas de sistema operativo que puede aplicar en su entorno, consulte el repositorio de GitHub GoogleCloudPlatform/osconfig .

Ejemplo 1

Cree una política de sistema operativo que instale un MSI de Windows descargado desde un depósito 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

Cree una política de sistema operativo que verifique si el servidor web Apache se está ejecutando en sus 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

Cree una política de sistema operativo que verifique si el servidor web Apache se está ejecutando en sus máquinas virtuales Linux. En este ejemplo, el script apache-validate.sh se almacena en un depósito de Cloud Storage. Para copiar el resultado a un depósito de Cloud Storage, el script 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

Cree una política de sistema operativo 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 el escaneo periódico CIS Nivel 1 con el período 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íticas del sistema operativo

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

  • Políticas del sistema operativo . Una o más políticas de sistema operativo que desee aplicar a su máquina virtual. Para descargar o crear una política, consulte Políticas del sistema operativo .

  • Máquinas virtuales de destino . Un conjunto de máquinas virtuales dentro de una única zona a las que desea aplicar la política. Dentro de una zona, puede limitar o restringir las máquinas virtuales mediante familias de sistemas operativos e incluir o excluir etiquetas. Puede 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 obtener una lista completa de los sistemas operativos y las versiones que admiten políticas de sistema operativo, consulte Detalles del sistema operativo .
    • Conjunto de inclusión: especifica las máquinas virtuales a las que se aplica la política del sistema operativo según las etiquetas del sistema o de la máquina virtual.
    • Conjunto de exclusión: especifica las máquinas virtuales que la política del sistema operativo debe ignorar según las etiquetas del sistema o de la máquina virtual.

    Tanto para los conjuntos de etiquetas de inclusión como de exclusión, se acepta una etiqueta de cadena única si coincide con la convención de nomenclatura utilizada por 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, consulte Etiquetado de recursos .

    Por ejemplo, puede seleccionar todas las máquinas virtuales de Ubuntu en su entorno de prueba y excluir aquellas que ejecutan Google Kubernetes Engine, especificando lo siguiente:

    • Familia de sistemas operativos: ubuntu
    • Incluye: env:test , env:staging
    • Excluir: goog-gke-node
  • Una tasa de implementación . Especifica el ritmo al que se aplican las políticas del sistema operativo a las máquinas virtuales. Las políticas del sistema operativo se implementan gradualmente para permitirle realizar un seguimiento del estado del sistema y realizar modificaciones si las actualizaciones provocan regresiones en su entorno. Un plan de implementación tiene los siguientes componentes:

    • Tamaño de la ola (presupuesto de interrupción): el número fijo o porcentaje de máquinas virtuales que pueden experimentar una implementación al mismo tiempo. Esto significa que en cualquier momento de la implementación solo se dirige a un número específico de máquinas virtuales.
    • Tiempo de espera: el tiempo entre el momento en que el servicio aplica políticas a la VM y el momento en que una VM se elimina del umbral de interrupción. Por ejemplo, un tiempo de espera de 15 minutos significa que el proceso de implementación debe esperar 15 minutos después de aplicar las políticas a una máquina virtual antes de poder eliminar la máquina virtual del umbral de interrupción y poder continuar con la implementación. El tiempo de espera ayuda a controlar la velocidad de una implementación y también le permite detectar y resolver posibles problemas de implementación con anticipación. Seleccione un tiempo que sea lo suficientemente largo para que pueda monitorear el estado de sus implementaciones.

    Por ejemplo, si establece un objetivo de 10 máquinas virtuales, establece el umbral de interrupción en 20 % y establece un tiempo de horneado de 15 minutos, en un momento dado, solo se programará la actualización de 2 máquinas virtuales. Después de actualizar cada VM, deben pasar 15 minutos antes de que la VM se elimine del umbral de interrupción y se agregue otra VM a la implementación.

    Para obtener más información sobre implementaciones, consulte Implementaciones .

Ejemplo de asignación de política de sistema operativo

Los siguientes ejemplos muestran cómo crear asignaciones de políticas de sistema operativo. Puede utilizar estos ejemplos para crear asignaciones de políticas de sistema operativo desde la CLI de Google Cloud o la API de configuración del sistema operativo.

  • Ejemplo 1: instala un paquete.
  • Ejemplo 2: ejecuta un script.
  • Ejemplo 3: especifica un repositorio de descarga e instala paquetes desde ese repositorio.

Para obtener una lista de ejemplos de asignaciones de políticas de sistema operativo que puede aplicar en su entorno, consulte el repositorio de GitHub GoogleCloudPlatform/osconfig .

Ejemplo 1

Cree una asignación de política de sistema operativo que instale un MSI de Windows descargado desde un depósito 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

Cree una asignación de política de sistema operativo que verifique si el servidor web Apache se está ejecutando en todas sus máquinas virtuales 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 sistema operativo que instala agentes de Google Cloud Observability 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

¿Qué sigue?