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 saperne di più, consulta la definizione delle risorse per OSPolicy.

Un'assegnazione dei criteri del sistema operativo è una risorsa API utilizzata da VM Manager per applicare i criteri del sistema operativo alle VM. Per maggiori informazioni, consulta la definizione delle risorse per OSPolicyAssignment.

Criterio di sistema operativo

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

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

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

    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 della risorsa associata. Ad esempio, puoi definire un singolo criterio per installare o eseguire il deployment di un agente in diverse distribuzioni e versioni del sistema operativo.

  • Risorse. Le specifiche necessarie alla VM per ottenere la configurazione selezionata. Sono supportati i seguenti tipi di risorse:

    • pkg: utilizzato per l'installazione o la rimozione di pacchetti Linux e Windows
    • repository: utilizzato per specificare da quali pacchetti software di repository è possibile installare
    • 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

Criteri di sistema operativo di esempio

Gli esempi riportati di seguito mostrano come creare criteri di sistema operativo. Puoi caricare questi criteri del sistema operativo nella console Google Cloud durante la creazione di un'assegnazione dei criteri del sistema operativo.

  • Esempio 1: installazione di 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 di benchmark CIS sulle VM che eseguono Container-Optimized OS (COS). Per maggiori informazioni sull'utilizzo dei criteri del sistema operativo per la scansione dei benchmark CIS, consulta Automatizzare l'abilitazione e il controllo dello stato di conformità CIS.

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

Esempio 1

Crea un criterio del sistema operativo che installa 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 di 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 installa gli agenti Google Cloud Observability su 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 del CIS Livello 1 con il periodo predefinito di una volta al giorno.

# 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

Assegnazione dei criteri del sistema operativo

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

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

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

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

    Sia per i set di etichette di inclusione che di esclusione, viene accettata una singola etichetta di stringa se corrisponde alla convenzione di denominazione utilizzata dal sistema. Tuttavia, la maggior parte delle etichette è specificata in coppie key:value. Per ulteriori informazioni sulle etichette, consulta Risorse per l'etichettatura.

    Ad esempio, puoi selezionare tutte le VM Ubuntu nel tuo ambiente di test ed escludere quelle che eseguono Google Kubernetes Engine specificando quanto segue:

    • Famiglia sistema operativo: ubuntu
    • Includi: env:test, env:staging
    • Escludi: goog-gke-node

  • Una frequenza di implementazione. Specifica la velocità con cui applicare i criteri di sistema operativo alle VM. I criteri del sistema operativo vengono implementati gradualmente per consentirti di monitorare l'integrità del sistema e apportare modifiche se gli aggiornamenti causano regressioni nel tuo ambiente. Un piano di implementazione include i seguenti componenti:

    • Dimensione dell'onda (budget per l'interruzione): il numero fisso o la percentuale di VM che possono essere implementate contemporaneamente. Ciò significa che, in qualsiasi momento dell'implementazione, verrà preso di mira solo un numero specificato 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 significa 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 l'implementazione può procedere. Il tempo di attesa consente di controllare la velocità di un'implementazione e di rilevare e risolvere in anticipo potenziali problemi di implementazione. Seleziona un periodo di tempo sufficiente per monitorare lo stato delle implementazioni.

    Ad esempio, se imposti un target di 10 VM, imposti la soglia di interruzione sul 20% e imposti un tempo di forno di 15 minuti, poi, in un determinato momento, sono pianificate solo 2 VM da aggiornare. Dopo aver aggiornato ogni VM, devono trascorrere 15 minuti prima che la VM venga rimossa dalla soglia di interruzione e venga aggiunta un'altra VM all'implementazione.

    Per ulteriori informazioni sulle implementazioni, consulta Implementazioni.

Esempio di assegnazione dei criteri del sistema operativo

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

  • Esempio 1: installazione di 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 assegnazioni di esempio dei criteri del sistema operativo che puoi applicare al tuo ambiente, consulta il repository GitHub di 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 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 Google Cloud Observability su 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

Che cosa succede dopo?