Crea vincoli CAI

Prima di iniziare

• Crea una libreria di criteri.

Framework dei vincoli

gcloud beta terraform vet utilizza policy Constraint Framework, che consistono in vincoli e modelli di vincolo. La differenza tra i due è la seguente:

• Un modello di vincolo è come una dichiarazione di funzione: definisce una regola in Rego e, facoltativamente, accetta parametri di input.
• Un vincolo è un file che fa riferimento a un modello di vincolo e definisce i parametri di input da passare e le risorse coperte dal criterio.

In questo modo puoi evitare ripetizioni. Puoi scrivere un modello di vincolo con una policy generica, quindi scrivere un numero qualsiasi di vincoli che forniscono parametri di input diversi o regole di corrispondenza delle risorse diverse.

Asset CAI e risorse Terraform

Gli asset Cloud Asset Inventory sono un formato standard di esportazione dei dati di Google disponibile per molte Google Cloud risorse. I dati CAI sono in genere disponibili solo dopo la creazione o l'aggiornamento di una risorsa. Tuttavia, convertendo le modifiche alle risorse Terraform in dati delle risorse CAI,gcloud beta terraform vet ti consente di scrivere un criterio una sola volta e utilizzarlo sia prima dell'applicazione sia come controllo di audit con strumenti compatibili.

Strumenti compatibili

I seguenti strumenti non sono prodotti Google ufficiali e non sono supportati. Tuttavia, potrebbero essere compatibili con i criteri scritti per gcloud beta terraform vet:

• Prospetto CFT
• Forseti

Crea un modello di vincolo

Prima di sviluppare il modello di vincolo, verifica che l'asset per cui vuoi scrivere una norma sia supportato sia da Cloud Asset Inventory sia da gcloud beta terraform vet.

La creazione di un modello di vincolo richiede i seguenti passaggi:

1. Raccogli i dati di esempio.
2. Scrivi Rego.
3. Testa la tua Rego.
4. Configura uno scheletro del modello di vincolo.
5. Incorpora Rego.
6. Configura un vincolo.

Raccogliere dati di esempio

Per scrivere un modello di vincolo, devi disporre di dati di esempio su cui operare. I vincoli basati su CAI operano sui dati degli asset CAI. Raccogli dati di esempio creando risorse del tipo appropriato ed esportandole come JSON, come descritto nella guida rapida di CAI.

Ecco un esempio di esportazione JSON per un indirizzo di calcolo:

[
  {
    "name": "//compute.googleapis.com/projects/789/regions/us-central1/addresses/my-internal-address",
    "asset_type": "compute.googleapis.com/Address",
    "ancestors: [
      "organization/123",
      "folder/456",
      "project/789"
    ],
    "resource": {
      "version": "v1",
      "discovery_document_uri": "https://www.googleapis.com/discovery/v1/apis/compute/v1/rest",
      "discovery_name": "Address",
      "parent": "//cloudresourcemanager.googleapis.com/projects/789",
      "data": {
        "address": "10.0.42.42",
        "addressType": "INTERNAL",
        "name": "my-internal-address",
        "region": "projects/789/global/regions/us-central1"
      }
    }
  },
]

Scrivere Rego

Dopo aver ottenuto i dati di esempio, puoi scrivere la logica per il modello di vincolo in Rego. Il tuo Rego deve avere una regola violations. L'asset in fase di revisione è disponibile come input.review. I parametri di vincolo sono disponibili come input.parameters. Ad esempio, per richiedere che gli asset compute.googleapis.com/Address abbiano un addressType consentito, scrivi:

# validator/gcp_compute_address_address_type_allowlist_constraint_v1.rego
package templates.gcp.GCPComputeAddressAddressTypeAllowlistConstraintV1

violation[{
  "msg": message,
  "details": metadata,
}] {
  asset := input.review
  asset.asset_type == "compute.googleapis.com/Address"

  allowed_address_types := input.parameters.allowed_address_types
  count({asset.resource.data.addressType} & allowed_address_types) >= 1
  message := sprintf(
    "Compute address %s has a disallowed address_type: %s",
    [asset.name, asset.resource.data.addressType]
  )
  metadata := {"asset": asset.name}
}

Assegna un nome al modello di vincolo

L'esempio precedente utilizza il nome GCPComputeAddressAddressTypeAllowlistConstraintV1. Si tratta di un identificatore univoco per ogni modello di vincolo. Ti consigliamo di seguire queste linee guida per la denominazione:

• Formato generale: GCP{resource}{feature}Constraint{version}. Utilizza la notazione CamelCase. In altre parole, metti in maiuscolo ogni nuova parola.
• Per i vincoli di una singola risorsa, segui i nomi dei gruppi gcloud per la denominazione delle risorse. Ad esempio, utilizza "compute" anziché "gce", "sql" anziché "cloud-sql" e "container-cluster" anziché "gke".
• Se un modello si applica a più di un tipo di risorsa, ometti la parte della risorsa e includi solo la funzionalità (ad esempio: "GCPAddressTypeAllowlistConstraintV1").
• Il numero di versione non segue il formato semver, ma è un singolo numero. In questo modo, ogni versione di un modello diventa un modello unico.

Ti consigliamo di utilizzare un nome per il file Rego che corrisponda al nome del modello di vincolo, ma utilizzando snake_case. In altre parole, converti il nome in minuscolo e separa le parole con _. Per l'esempio precedente, il nome file consigliato è gcp_compute_address_address_type_allowlist_constraint_v1.rego

Testare Rego

Puoi testare Rego manualmente con Rego Playground. Assicurati di utilizzare dati non sensibili.

Ti consigliamo di scrivere test automatizzati. Inserisci i dati di esempio raccolti in validator/test/fixtures/<constraint filename>/assets/data.json e fai riferimento a questi nel file di test nel seguente modo:

# validator/gcp_compute_address_address_type_allowlist_constraint_v1_test.rego
package templates.gcp.GCPComputeAddressAddressTypeAllowlistConstraintV1

import data.test.fixtures.gcp_compute_address_address_type_allowlist_constraint_v1_test.assets as assets

test_violation_with_disallowed_address_type {
  parameters := {
    "allowed_address_types": "EXTERNAL"
  }
  violations := violation with input.review as assets[_]
    with input.parameters as parameters
  count(violations) == 1
}

Inserisci il Rego e il test nella cartella validator della libreria dei criteri.

Configurare lo scheletro di un modello di vincolo

Dopo aver creato e testato una regola Rego funzionante, devi pacchettizzarla come modello di vincolo. Constraint Framework utilizza le definizioni di risorse personalizzate di Kubernetes come contenitore per le norme Rego.

Il modello di vincolo definisce anche quali parametri sono consentiti come input dai vincoli, utilizzando lo schema OpenAPI V3.

Utilizza lo stesso nome per lo scheletro che hai utilizzato per Rego. In particolare:

• Utilizza lo stesso nome file del tuo Rego. Esempio: gcp_compute_address_address_type_allowlist_constraint_v1.yaml
• spec.crd.spec.names.kind deve contenere il nome del modello
• metadata.name deve contenere il nome del modello, ma in minuscolo

Inserisci lo scheletro del modello di vincolo in policies/templates.

Per l'esempio riportato sopra:

# policies/templates/gcp_compute_address_address_type_allowlist_constraint_v1.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: gcpcomputeaddressaddresstypeallowlistconstraintv1
spec:
  crd:
    spec:
      names:
        kind: GCPComputeAddressAddressTypeAllowlistConstraintV1
      validation:
        openAPIV3Schema:
          properties:
            allowed_address_types:
              description: "A list of address_types allowed, for example: ['INTERNAL']"
              type: array
              items:
                type: string
  targets:
    - target: validation.gcp.forsetisecurity.org
      rego: |
            #INLINE("validator/gcp_compute_address_address_type_allowlist_constraint_v1.rego")
            #ENDINLINE

Incorpora Rego

A questo punto, seguendo l'esempio precedente, il layout della directory è il seguente:

| policy-library/
|- validator/
||- gcp_compute_address_address_type_allowlist_constraint_v1.rego
||- gcp_compute_address_address_type_allowlist_constraint_v1_test.rego
|- policies
||- templates
|||- gcp_compute_address_address_type_allowlist_constraint_v1.yaml

Se hai clonato il repository della libreria di criteri fornito da Google, puoi eseguire make build per aggiornare automaticamente i modelli di vincolo in policies/templates con Rego definito in validator.

Configurare un vincolo

I vincoli contengono tre informazioni che gcloud beta terraform vet deve avere per applicare e segnalare correttamente le violazioni:

• severity: low, medium o high
• match: parametri per determinare se un vincolo si applica a una risorsa specifica. Sono supportati i seguenti parametri di corrispondenza:
  • ancestries: Un elenco di percorsi di discendenza da includere utilizzando la corrispondenza in stile glob
  • excludedAncestries: (facoltativo) un elenco di percorsi di discendenza da escludere utilizzando la corrispondenza in stile glob.
• parameters: valori per i parametri di input del modello di vincolo.

Assicurati che kind contenga il nome del modello di vincolo. Ti consigliamo di impostare metadata.name su uno slug descrittivo.

Ad esempio, per consentire solo i tipi di indirizzo INTERNAL utilizzando il modello di vincolo dell'esempio precedente, scrivi:

# policies/constraints/gcp_compute_address_internal_only.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPComputeAddressAddressTypeAllowlistConstraintV1
metadata:
  name: gcp_compute_address_internal_only
spec:
  severity: high
  match:
    ancestries:
    - "**"
  parameters:
    allowed_address_types:
    - "INTERNAL"

Esempi di corrispondenza:

Se l'indirizzo di una risorsa corrisponde ai valori di ancestries e excludedAncestries, viene escluso.

Limitazioni

I dati del piano Terraform forniscono la migliore rappresentazione disponibile dello stato effettivo dopo l'applicazione. Tuttavia, in molti casi, lo stato dopo l'applicazione potrebbe non essere noto perché viene calcolato lato server. In questi casi, i dati non sono disponibili nemmeno nelle risorse CAI convertite.

La creazione di percorsi di discendenza CAI fa parte della procedura di convalida delle norme. Utilizza il progetto predefinito fornito per aggirare gli ID progetto sconosciuti. Nel caso in cui non venga fornito un progetto predefinito, il percorso di discendenza è impostato su organizations/unknown.

Puoi vietare l'ascendenza sconosciuta aggiungendo il seguente vincolo:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPAlwaysViolatesConstraintV1
metadata:
  name: disallow_unknown_ancestry
  annotations:
    description: |
      Unknown ancestry is not allowed; use --project=<project> to set a
      default ancestry
spec:
  severity: high
  match:
    ancestries:
    - "organizations/unknown"
  parameters: {}

Risorse supportate

Se vuoi che gcloud beta terraform vet aggiunga il supporto per una risorsa non presente in questo elenco, apri una richiesta di miglioramento e valuta la possibilità di contribuire con il codice.

L'elenco delle risorse supportate dipende dalla versione di gcloud beta terraform vet installata. Di seguito è riportato l'elenco attuale delle risorse supportate: