Règles d'OS et attribution de règles d'OS

Une règle du système d'exploitation est un fichier contenant la configuration déclarative des ressources du système d'exploitation, telles que les packages, les dépôts, les fichiers ou les ressources personnalisées définies par des scripts. Pour en savoir plus, consultez la définition des ressources associées à OSPolicy.

Une attribution de règles du système d'exploitation est une ressource d'API utilisée par VM Manager pour appliquer des règles du système d'exploitation aux VM. Pour en savoir plus, consultez la définition des ressources associées à OSPolicyAssignment.

Règle du système d'exploitation

Une règle du système d'exploitation est un fichier JSON ou YAML comportant trois sections :

  • Mode : comportement des règles. Les deux modes suivants sont disponibles :

    • Validation : pour ce mode, la règle vérifie si les ressources se trouvent dans l'état souhaité sans effectuer aucune action.
    • Enforcement : pour ce mode, la règle vérifie si les ressources se trouvent dans l'état souhaité et, si ce n'est pas le cas, effectue les actions nécessaires pour les amener à cet état.

    Pour les deux modes, VM Manager génèrent des rapports sur la conformité avec la règle du système d'exploitation et les ressources associées.

  • Groupes de ressources : nom et version du système d'exploitation auxquels les spécifications de ressources associées s'appliquent. Par exemple, vous pouvez définir une seule règle pour installer ou déployer un agent sur différentes distributions et versions de système d'exploitation.

  • Ressources : spécifications requises par la VM pour atteindre la configuration sélectionnée. Vous pouvez spécifier un maximum de 10 ID de ressource dans chaque groupe de ressources. Les types de ressources suivants sont acceptés :

    • pkg : pour l'installation ou la suppression de packages Linux et Windows
    • repository : pour spécifier à partir de quel dépôt les packages logiciels peuvent être installés
    • exec : pour permettre l'exécution d'un script shell ad hoc (/bin/sh) ou PowerShell

    • file : pour gérer des fichiers sur le système

Exemples de règles du système d'exploitation

Les exemples suivants montrent comment créer des règles de système d'exploitation. Vous pouvez importer ces règles dans la console Google Cloud lorsque vous créez une attribution de règles du système d'exploitation.

  • Exemple 1 : installation d'un package.
  • Exemple 2 : exécution d'un script.
  • Exemple 3 : exécution d'un script stocké dans un bucket Cloud Storage et copie du fichier de sortie dans un bucket Cloud Storage.
  • Exemple 4 : spécification d'un dépôt de téléchargement et installation de packages à partir de ce dépôt.
  • Exemple 5 : configuration de l'analyse comparative CIS sur les VM exécutant Container-Optimized OS (COS). Pour en savoir plus sur l'utilisation des règles de système d'exploitation pour l'analyse comparative CIS, consultez Automatiser l'activation et la vérification de l'état de conformité CIS.

Pour obtenir la liste complète des exemples de règles de système d'exploitation que vous pouvez appliquer dans votre environnement, consultez le dépôt GitHub GoogleCloudPlatform/osconfig.

Exemple 1

Créez une règle de système d'exploitation qui installe un fichier MSI Windows téléchargé à partir d'un bucket 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

Exemple 2

Créez une règle de système d'exploitation qui vérifie si le serveur Web Apache s'exécute sur vos VM 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

Exemple 3

Créez une règle de système d'exploitation qui vérifie si le serveur Web Apache s'exécute sur vos VM Linux. Dans cet exemple, le script apache-validate.sh est stocké dans un bucket Cloud Storage. Pour copier la sortie dans un bucket Cloud Storage, le script apache-enforce.sh doit inclure une commande semblable à ce qui suit :

      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

Exemple 4

Créez une règle de système d'exploitation qui installe des agents Google Cloud Observability sur des VM 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

Exemple 5

Configurez l'analyse CIS périodique de niveau 1 avec la période par défaut d'une fois par jour.

# 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

Attribution de règles de système d'exploitation

Une attribution de règles de système d'exploitation comprend les sections suivantes :

  • Règles de système d'exploitation Une ou plusieurs règles de système d'exploitation que vous souhaitez appliquer à votre VM. Pour télécharger ou créer une règle, consultez la section Règles de système d'exploitation.

  • VM cibles Un ensemble de VM dans une seule zone à laquelle vous souhaitez appliquer la règle. Dans une zone, vous pouvez limiter ou restreindre l'accès aux VM en spécifiant les noms de système d'exploitation. Vous pouvez ausi inclure ou exclure des libellés. Vous pouvez sélectionner une combinaison des options suivantes :

    • Zone : spécifie la zone Google Cloud dans laquelle vous souhaitez déployer l'attribution de règles de système d'exploitation.
    • Nom et version du système d'exploitation : spécifie le nom court et la version du système d'exploitation cible auquel la règle s'applique. Pour obtenir un exemple de ciblage de plusieurs systèmes d'exploitation, reportez-vous à l'exemple 4.

    Pour filtrer les VM en fonction du système d'exploitation, utilisez l'un des noms courts suivants dans vos fichiers YAML de règles de système d'exploitation :

    Nom complet Nom court
    CentOS centos
    Container-Optimized OS (COS) cos
    Debian debian
    OpenSUSE Leap opensuse-leap
    Oracle Linux ol
    Red Hat Enterprise Linux (RHEL) rhel
    Rocky Linux rocky
    SUSE Linux Enterprise Server (SLES) sles
    Ubuntu ubuntu
    Windows Server windows

    Pour obtenir la liste complète des systèmes d'exploitation et des versions compatibles avec les règles de système d'exploitation, consultez la section Détails des systèmes d'exploitation.

    • Ensemble d'inclusion : spécifie les VM auxquelles la règle de système d'exploitation s'applique en fonction de libellés de VM ou de système.
    • Ensemble d'exclusion : spécifie les VM que la règle de système d'exploitation doit ignorer en fonction des libellés de VM ou du système.

    Pour les ensembles de libellés d'inclusion et d'exclusion, un seul libellé de chaîne est accepté si il correspond à la convention d'attribution de noms utilisée par le système. Cependant, la plupart des libellés sont spécifiés dans des paires key:value. Pour en savoir plus sur les libellés, consultez la section Ajouter des libellés à des ressources.

    Par exemple, vous pouvez sélectionner toutes les VM Ubuntu dans votre environnement de test et exclure celles qui exécutent Google Kubernetes Engine, en spécifiant les éléments suivants :

    • Nom court du système d'exploitation : ubuntu
    • Inclure : env:test, env:staging
    • Exclure : goog-gke-node

  • Un taux de déploiement Spécifie le rythme auquel appliquer les règles de système d'exploitation aux VM. Les règles de système d'exploitation sont déployées progressivement pour vous permettre de suivre l'état du système et d'apporter des modifications si les mises à jour entraînent des régressions dans votre environnement. Un plan de déploiement se compose des éléments suivants :

    • Taille d'onde (budget d'interruption) : nombre fixe ou pourcentage de VM pouvant faire l'objet d'un déploiement simultanément. Ainsi, à tout moment du déploiement, seul un nombre spécifié de VM est ciblé.
    • Temps d'attente : délai entre le moment où le service applique des règles à la VM et le moment où une VM est supprimée du seuil d'interruption. Par exemple, un temps d'attente de 15 minutes signifie que la VM pourra être retirée du seuil d'interruption et le déploiement s'effectuer 15 minutes après l'application des règles à une VM. Le temps d'attente permet de contrôler la vitesse de déploiement. Il vous permet aussi de détecter et de résoudre les éventuels problèmes de déploiement de manière anticipée. Sélectionnez une période suffisamment longue pour que vous puissiez surveiller l'état de vos déploiements.

    Par exemple, si vous définissez un objectif de 10 VM, le seuil d'interruption à 20 % et un délai de traitement de 15 minutes, seules deux VM sont programmées pour la mise à jour à tout moment. Une fois chaque VM mise à jour, 15 minutes doivent s'écouler avant que la VM ne soit supprimée du seuil d'interruption et qu'une autre VM soit ajoutée au processus de déploiement.

    Pour plus d'informations sur les déploiements, consultez la section Déploiements.

Exemple d'attribution de règles de système d'exploitation

Les exemples suivants montrent comment créer des attributions de règles de système d'exploitation. Vous pouvez utiliser ces exemples pour créer des attributions de règles de système d'exploitation depuis la Google Cloud CLI ou l'API OS Config.

  • Exemple 1 : installation d'un package.
  • Exemple 2 : exécution d'un script.
  • Exemple 3 : spécification d'un dépôt de téléchargement et installation de packages à partir de ce dépôt.
  • Exemple 4 : attribution de règles de système d'exploitation qui s'applique à plusieurs systèmes d'exploitation.

Pour obtenir une liste d'exemples d'attributions de règles de système d'exploitation que vous pouvez appliquer dans votre environnement, consultez le dépôt GitHub GoogleCloudPlatform/osconfig.

Exemple 1

Créez une attribution de règles de système d'exploitation qui installe un fichier MSI Windows téléchargé à partir d'un bucket 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

Exemple 2

Créez une attribution de règles de système d'exploitation qui vérifie si le serveur Web Apache est exécuté sur toutes vos VM 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

Exemple 3

Créez une attribution de règles de système d'exploitation qui installe des agents Google Cloud Observability sur des VM 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

Exemple 4

Créez une attribution de règles de système d'exploitation qui s'applique à plusieurs systèmes d'exploitation Linux et Windows.

# An OS policy assignment that applies to multiple Linux and Windows operating systems.
id: multi-os
mode: VALIDATION
resourceGroups:
  - inventoryFilters:
      - osShortName: debian
      - osShortName: centos
      - osShortName: ubuntu
      - osShortName: rhel
      - osShortName: rocky
      - osShortName: cos
      - osShortName: opensuse-leap
      - osShortName: ol
      - osShortName: sles
    resources:
      - id: linux
        exec:
          validate:
            interpreter: SHELL
            # Linux-specific script.
            # Exit code of 100 = resource is in the desired state
            script: |
              exit 100
  - inventoryFilters:
      - osShortName: windows
    resources:
      - id: windows
        exec:
          validate:
            interpreter: POWERSHELL
            # Windows-specific script.
            # Exit code of 100 = resource is in the desired state
            script: |
              exit 100

Étapes suivantes