Criteri del sistema operativo e assegnazione dei criteri

Un criterio del sistema operativo è un file che contiene la configurazione dichiarativa per le risorse del sistema operativo come pacchetti, repository, file o risorse personalizzate definite dagli script. Per ulteriori informazioni, consulta la definizione della risorsa per OSPolicy.

Un'assegnazione del criterio del sistema operativo è una risorsa API utilizzata da VM Manager per applicare i criteri del sistema operativo alle VM. Per ulteriori informazioni, consulta la definizione della risorsa per OSPolicyAssignment.

Criterio sistema operativo

Un criterio del sistema operativo è un file JSON o YAML con tre sezioni:

  • Modalità. Il comportamento del criterio. Sono disponibili le seguenti due modalità:

    • Validation: in questa modalità, il criterio controlla se le risorse sono nello stato scelto, ma non esegue alcuna azione.
    • Enforcement: per questa modalità, il criterio controlla se le risorse sono nello stato scelto e, in caso contrario, esegue le azioni necessarie per impostarle su questo stato.

    Per entrambe le modalità, VM Manager segnala la conformità per i criteri del sistema operativo e le risorse associate.

  • Gruppi di risorse. Il nome e la versione del sistema operativo a cui si applicano le specifiche delle risorse associate. Ad esempio, puoi definire un singolo criterio per installare o implementare un agente su diverse distribuzioni e versioni del sistema operativo.

  • Risorse. Le specifiche necessarie per consentire alla VM di raggiungere la configurazione selezionata. Puoi specificare un massimo di 10 ID risorsa in ogni gruppo di risorse. Sono supportati i seguenti tipi di risorse:

    • pkg: utilizzato per installare o rimuovere pacchetti Linux e Windows
    • repository: utilizzato per specificare da quale repository è possibile installare i pacchetti software
    • exec: utilizzato per attivare l'esecuzione di una shell ad hoc (/bin/sh) o di uno script PowerShell
    • file: utilizzato per gestire i file sul sistema

Esempi di criteri del sistema operativo

Gli esempi riportati di seguito mostrano come creare criteri del sistema operativo. Puoi caricare questi criteri del sistema operativo nella console Google Cloud quando crei un'assegnazione di criteri del sistema operativo.

  • Esempio 1: installa un pacchetto.
  • Esempio 2: esegue uno script.
  • Esempio 3: specifica un repository di download e installa i pacchetti da quel repository.
  • Esempio 4: configura la scansione del benchmark CIS sulle VM che eseguono il sistema operativo Container-Optimized OS (COS). Per ulteriori informazioni sull'utilizzo dei criteri del sistema operativo per la scansione del benchmark CIS, consulta Automatizzare l'attivazione e il controllo dello stato di conformità al CIS.

Per un elenco completo di criteri di sistema operativo di esempio che puoi applicare nel tuo ambiente, consulta il repository GitHub GoogleCloudPlatform/osconfig.

Esempio 1

Crea un criterio del sistema operativo che installi un file MSI di Windows scaricato da 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

Esempio 2

Crea un criterio del sistema operativo che verifichi se il server web Apache è in esecuzione sulle tue 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

Esempio 3

Crea un criterio del sistema operativo che installi gli agenti di Google Cloud Observability sulle 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

Esempio 4

Configura la scansione periodica CIS di Livello 1 con il periodo predefinito di una volta al giorno.

# 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

Assegnazione dei criteri del sistema operativo

Un'assegnazione dei criteri del sistema operativo contiene le seguenti sezioni:

  • Criteri del sistema operativo. Uno o più criteri del sistema operativo da applicare alla VM. Per scaricare o creare un criterio, consulta Criteri del sistema operativo.

  • VM target. Un insieme di VM all'interno di un'unica zona a cui vuoi applicare il criterio. All'interno di una zona puoi limitare o restringere le VM utilizzando le famiglie di sistemi operativi e includere o escludere le etichette. Puoi selezionare una combinazione delle seguenti opzioni:

    • Famiglie di sistemi operativi: specifica i sistemi operativi di destinazione a cui si applica il criterio del sistema operativo. Per un elenco completo dei sistemi operativi e delle versioni che supportano i criteri del sistema operativo, consulta Dettagli del sistema operativo.
    • Set di inclusione: specifica le VM a cui si applica il criterio del sistema operativo in base alle etichette della VM o del sistema.
    • Set di esclusione: specifica le VM che il criterio del sistema operativo deve ignorare in base alle etichette della VM o del sistema.

    Per i set di etichette di inclusione ed esclusione, è accettata una singola etichetta di stringa se corrisponde alla convenzione di denominazione utilizzata dal sistema. Tuttavia, la maggior parte delle etichette viene specificata in coppie key:value. Per saperne di più sulle etichette, consulta Etichettare le risorse.

    Ad esempio, puoi selezionare tutte le VM Ubuntu nel tuo ambiente di test ed escludere quelle su cui è in esecuzione Google Kubernetes Engine specificando quanto segue:

    • Famiglia di sistemi operativi: ubuntu
    • Sono inclusi: env:test, env:staging
    • Escludi: goog-gke-node

  • Una percentuale di implementazione. Specifica la velocità con cui applicare i criteri del sistema operativo alle VM. Le norme del sistema operativo vengono implementate gradualmente per consentirti di monitorare l'integrità del sistema e apportare modifiche se gli aggiornamenti causano regressioni nell'ambiente. Un piano di implementazione è costituito dai seguenti componenti:

    • Dimensioni dell'ondata (budget di interruzione): il numero fisso o la percentuale di VM che possono essere implementate contemporaneamente. Ciò significa che in qualsiasi momento dell'implementazione viene scelto come target solo un numero specifico di VM.
    • Tempo di attesa: il tempo che intercorre tra il momento in cui il servizio applica i criteri alla VM e il momento in cui una VM viene rimossa dalla soglia di interruzione. Ad esempio, un tempo di attesa di 15 minuti indica che il processo di implementazione deve attendere 15 minuti dopo l'applicazione dei criteri a una VM prima di poter rimuovere la VM dalla soglia di interruzione e procedere con l'implementazione. Il tempo di attesa consente di controllare la velocità di implementazione e anche di rilevare e risolvere tempestivamente potenziali problemi di implementazione. Seleziona un periodo di tempo sufficiente per monitorare lo stato degli implementamenti.

    Ad esempio, se imposti un target di 10 VM, imposti la soglia di interruzione su 20% e imposti un tempo di applicazione di 15 minuti, in un determinato momento solo 2 VM sono programmate per essere aggiornate. Dopo l'aggiornamento di ogni VM, devono trascorrere 15 minuti prima che la VM venga rimossa dalla soglia di interruzione e un'altra VM venga aggiunta al rollout.

    Per ulteriori informazioni sulle implementazioni, consulta la sezione Implementazioni.

Esempio di assegnazione dei criteri del sistema operativo

Gli esempi riportati di seguito mostrano come creare assegnazioni dei criteri del sistema operativo. Puoi utilizzare questi esempi per creare assegnazioni di criteri del sistema operativo da Google Cloud CLI o dall'API OS Config.

  • Esempio 1: installa un pacchetto.
  • Esempio 2: esegue uno script.
  • Esempio 3: specifica un repository di download e installa i pacchetti da quel repository.

Per un elenco di esempi di assegnazioni di criteri del sistema operativo che puoi applicare nel tuo ambiente, consulta il repository GitHub GoogleCloudPlatform/osconfig.

Esempio 1

Crea un'assegnazione dei criteri del sistema operativo che installa un file MSI di Windows scaricato da 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

Esempio 2

Crea un'assegnazione dei criteri del sistema operativo che verifichi se il server web Apache è in esecuzione su tutte le tue 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

Esempio 3

Crea un'assegnazione dei criteri del sistema operativo che installa gli agenti di Google Cloud Observability sulle 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

Passaggi successivi