Creazione di vincoli Terraform

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Prima di iniziare

• Crea una libreria di criteri.

Framework dei vincoli

gcloud beta terraform vet utilizza i criteri del framework dei vincoli, 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 al modello e le risorse coperte dal criterio.

In questo modo eviterai le ripetizioni. Puoi scrivere un modello di vincolo con un criterio generico, quindi scrivere un numero qualsiasi di vincoli che forniscono parametri di input diversi o regole di corrispondenza delle risorse diverse.

Crea un modello di vincolo

Per creare un modello di vincolo:

1. Raccogli dati di esempio.
2. Scrivi Rego.
3. Testa il tuo Rego.
4. Configura la bozza di un modello di vincolo.
5. Rego in linea.
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 Terraform operano sui dati di modifica delle risorse, che provengono dalla chiave resource_changes del JSON del piano Terraform.

Ad esempio, il tuo JSON potrebbe avere il seguente aspetto:

// tfplan.json
{
  "format_version": "0.2",
  "terraform_version": "1.0.10",
  "resource_changes": [
    {
      "address": "google_compute_address.internal_with_subnet_and_address",
      "mode": "managed",
      "type": "google_compute_address",
      "name": "internal_with_subnet_and_address",
      "provider_name": "registry.terraform.io/hashicorp/google",
      "change": {
        "actions": [
          "create"
        ],
        "before": null,
        "after": {
          "address": "10.0.42.42",
          "address_type": "INTERNAL",
          "description": null,
          "name": "my-internal-address",
          "network": null,
          "prefix_length": null,
          "region": "us-central1",
          "timeouts": null
        },
        "after_unknown": {
          "creation_timestamp": true,
          "id": true,
          "network_tier": true,
          "project": true,
          "purpose": true,
          "self_link": true,
          "subnetwork": true,
          "users": true
        },
        "before_sensitive": false,
        "after_sensitive": {
          "users": []
        }
      }
    }
  ],
  // other data
}

Scrivi Rego

Dopo aver ottenuto i dati di esempio, puoi scrivere la logica del modello di vincolo in Rego. Rego deve avere una regola violations. La modifica della risorsa in fase di revisione è disponibile come input.review. I parametri del vincolo sono disponibili come input.parameters. Ad esempio, per richiedere che le risorse google_compute_address abbiano un valore address_type consentito, scrivi:

# validator/tf_compute_address_address_type_allowlist_constraint_v1.rego
package templates.gcp.TFComputeAddressAddressTypeAllowlistConstraintV1

violation[{
  "msg": message,
  "details": metadata,
}] {
  resource := input.review
  resource.type == "google_compute_address"

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

Assegna un nome al modello di vincolo

L'esempio precedente utilizza il nome TFComputeAddressAddressTypeAllowlistConstraintV1. Si tratta di un identificatore univoco per ciascun modello di vincolo. Ti consigliamo di seguire queste linee guida per l'assegnazione dei nomi:

• Formato generale: TF{resource}{feature}Constraint{version}. Utilizza CamelCase. In altre parole, utilizza lettere maiuscole per ogni nuova parola.
• Per i vincoli relativi a una singola risorsa, segui le convenzioni del provider Terraform per la denominazione dei prodotti. Ad esempio, per google_tags_tag il nome del prodotto è tags anche se il nome dell'API è resourcemanager.
• Se un modello si applica a più tipi di risorsa, ometti la parte della risorsa e includi solo la funzionalità (esempio: "TFAddressTypeAllowlistConstraintV1").
• Il numero di versione non segue il formato di server: è solo un numero singolo. In questo modo, ogni versione di un modello diventa un modello unico.

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

Testa Rego

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

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

# validator/tf_compute_address_address_type_allowlist_constraint_v1_test.rego
package templates.gcp.TFComputeAddressAddressTypeAllowlistConstraintV1

import data.test.fixtures.tf_compute_address_address_type_allowlist_constraint_v1_test.resource_changes as resource_changes

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

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

Configura la struttura di un modello di vincolo

Dopo aver creato una regola Rego funzionante e testata, devi pacchettizzarla come modello di vincolo. Il framework dei vincoli utilizza le definizioni di risorse personalizzate di Kubernetes come container per il criterio Rego.

Il modello di vincolo definisce anche i parametri consentiti come input dei vincoli, utilizzando lo schema OpenAPI V3.

Usa lo scheletro utilizzato per il Rego. In particolare:

• Utilizza lo stesso nome file utilizzato per Rego. Esempio: tf_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

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

Nell'esempio precedente:

# policies/templates/tf_compute_address_address_type_allowlist_constraint_v1.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: tfcomputeaddressaddresstypeallowlistconstraintv1
spec:
  crd:
    spec:
      names:
        kind: TFComputeAddressAddressTypeAllowlistConstraintV1
      validation:
        openAPIV3Schema:
          properties:
            allowed_address_types:
              description: "A list of address_types allowed, for example: ['INTERNAL']"
              type: array
              items:
                type: string
  targets:
    - target: validation.resourcechange.terraform.cloud.google.com
      rego: |
            #INLINE("validator/tf_compute_address_address_type_allowlist_constraint_v1.rego")
            #ENDINLINE

Incorpora il Rego

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

| policy-library/
|- validator/
||- tf_compute_address_address_type_allowlist_constraint_v1.rego
||- tf_compute_address_address_type_allowlist_constraint_v1_test.rego
|- policies
||- templates
|||- tf_compute_address_address_type_allowlist_constraint_v1.yaml

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

Configura un vincolo

I vincoli contengono tre informazioni necessarie a gcloud beta terraform vet per far rispettare e segnalare correttamente le violazioni:

• severity: low, medium o high
• match: parametri per determinare se un vincolo si applica a una determinata risorsa. Sono supportati i seguenti parametri di corrispondenza:
  • addresses: un elenco di indirizzi di risorse da includere utilizzando le corrispondenze di tipo glob
  • excludedAddresses: (facoltativo) un elenco di indirizzi di risorse da escludere utilizzando la corrispondenza di tipo glob.
• parameters: valori dei parametri di input del modello di vincolo.

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

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

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

Esempi di corrispondenza:

Corrispondenza indirizzo	Description
"modulo.**"	Tutte le risorse in qualsiasi modulo
"module.my_module.**"	Tutto nel modulo "my_module"
`**.google_compute_global_forwarding_rule.*`	Tutte le risorse google_compute_global_forwarding_rule in qualsiasi modulo
`module.my_module.google_compute_global_forwarding_rule.*`	Tutte le risorse google_compute_global_forwarding_rule in "my_module"

Se un indirizzo della risorsa corrisponde ai valori in addresses e excludedAddresses, viene escluso.

Limitazioni

I dati del piano Terraform offrono 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 sul lato server.

La creazione di percorsi di discendenza CAI fa parte del processo di convalida dei criteri. 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 per impostazione predefinita.

Puoi impedire la discendenza 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

Puoi creare vincoli di modifica delle risorse per qualsiasi risorsa Terraform da qualsiasi provider Terraform.