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

Une règle d'OS est un fichier contenant la configuration déclarative des ressources d'OS 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 stratégie d'OS est une ressource d'API utilisée par VM Manager pour appliquer des règles de système d'exploitation aux VM. Pour en savoir plus, consultez la définition des ressources associées à OSPolicyAssignment.

Règle sur l'OS

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

  • Mode de chaque champ. Comportement des règles. Les deux modes suivants sont disponibles:

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

    Pour les deux modes, VM Manager signale la conformité pour la règle d'OS 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 stratégie 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 souhaitée. Les types de ressources suivants sont acceptés :

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

Exemples de règles d'OS

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

  • Exemple 1 : installe un package.
  • Exemple 2 : exécute un script.
  • Exemple 3 : spécifie un dépôt de téléchargement et installe des packages à partir de ce dépôt.
  • Exemple 4 : configurer l'analyse comparative CIS sur les VM exécutant Container-Optimized OS (COS)  Pour en savoir plus sur l'utilisation des règles d'OS pour l'analyse comparative CIS, consultez la page 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 d'OS qui installe un fichier MSI Windows téléchargé à partir d'un bucket 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

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.

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

Exemple 3

Créez une règle d'OS qui installe des agents d'observabilité Google Cloud sur les VM 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

Exemple 4

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

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

Attribution des règles d'OS

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

  • Règles d'OS 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 du 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 utilisant les familles d'OS, et inclure ou exclure des libellés. Vous pouvez sélectionner une combinaison des options suivantes:

    • Familles de système d'exploitation: spécifie les systèmes d'exploitation cibles auxquels la règle de système d'exploitation s'applique. Pour obtenir la liste complète des systèmes d'exploitation et des versions compatibles avec les règles d'OS, consultez la page 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 d'étiquettes d'inclusion et d'exclusion, une seule étiquette de chaîne est acceptée si elle correspond à la convention de dénomination 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:

    • Famille d'OS : ubuntu
    • Inclure : env:test, env:staging
    • Exclure : goog-gke-node

  • Un taux de déploiement. Spécifie le rythme auquel appliquer les règles d'OS aux VM. Les règles d'OS 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 comprend les composants 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 de perturbation. Par exemple, un temps d'attente de 15 minutes signifie que le processus de déploiement doit attendre 15 minutes après l'application des règles à une VM avant de pouvoir retirer la VM du seuil d'interruption et de procéder au déploiement. Le temps d'attente permet de contrôler la vitesse de déploiement, et vous permet de détecter et de résoudre les problèmes de déploiement potentiels de manière anticipée. Sélectionnez une période suffisante pour surveiller l'état de vos déploiements.

    Par exemple, si vous définissez un objectif de 10 VM, définissez le seuil de perturbation à 20 % et définissez un délai d'intégration de 15 minutes, donc à un moment donné, seules deux VM sont mises à jour. Une fois chaque VM mise à jour, 15 minutes doivent s'écouler avant que la VM ne soit supprimée du seuil de perturbation et une autre VM est ajoutée au déploiement.

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

Exemple d'attribution de règles OS

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 d'OS depuis Google Cloud CLI ou l'API OS Config.

  • Exemple 1 : installe un package.
  • Exemple 2 : exécute un script.
  • Exemple 3 : spécifie un dépôt de téléchargement et installe des packages à partir de ce dépôt.

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

Exemple 1

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

Exemple 2

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

Exemple 3

Crée une attribution de règle d'OS qui installe les agents d'observabilité Google Cloud sur les VM 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

Étape suivante