Convalida le app in base ai criteri aziendali in una pipeline CI

Se la tua organizzazione utilizza Policy Controller per gestire i criteri nei cluster Google Kubernetes Engine, puoi convalidare la configurazione di deployment di un'app nella relativa pipeline di integrazione continua (CI). Questo tutorial mostra come ottenere questo risultato. La convalida dell'app è utile se sei uno sviluppatore che crea una pipeline CI per un'app o un ingegnere della piattaforma che crea un modello di pipeline CI per più team di app.

Questa pagina è rivolta agli amministratori IT e agli operatori che vogliono assicurarsi che tutte le risorse in esecuzione all'interno della piattaforma cloud soddisfino i requisiti di conformità dell'organizzazione fornendo e mantenendo l'automazione per l'audit o l'applicazione e che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.

I criteri sono una parte importante della sicurezza e della conformità di un'organizzazione. Policy Controller consente alla tua organizzazione di gestire questi criteri in modo centralizzato e dichiarativo per tutti i cluster. In qualità di sviluppatore, puoi sfruttare la natura centralizzata e dichiarativa di questi criteri. Puoi utilizzare queste caratteristiche per convalidare l'app in base a questi criteri il prima possibile nel flusso di lavoro di sviluppo. L'apprendimento delle violazioni delle policy nella pipeline CI anziché durante il deployment presenta due vantaggi principali: consente di shift left sulla sicurezzae di ridurre il ciclo di feedback, riducendo il tempo e i costi necessari per correggere queste violazioni.

Questo tutorial utilizza Cloud Build come strumento CI e un repository GitHub di esempio contenente i criteri per le dimostrazioni.

Risorse

Questo tutorial utilizza diversi strumenti Kubernetes. Questa sezione spiega quali sono questi strumenti, come interagiscono tra loro e se puoi sostituirli con qualcos'altro.

Gli strumenti utilizzati in questo tutorial includono i seguenti:

Policy Controller: si basa sul progetto open source Open Policy Agent - Gatekeeper. Policy Controller applica i criteri relativi agli oggetti creati in un cluster Kubernetes (ad esempio, impedisce l'utilizzo di un'opzione specifica o impone l'utilizzo di un'etichetta specifica). Questi criteri sono chiamati vincoli. I vincoli sono definiti come risorse personalizzate di Kubernetes. Policy Controller è disponibile come parte di GKE, ma puoi utilizzare Open Policy Agent - Gatekeeper anziché Policy Controller per la tua implementazione.
GitHub: in questo tutorial utilizziamo GitHub per ospitare i repository Git: uno per un' app di esempio e uno contenente i vincoli per Policy Controller. Per semplicità, i due repository sono due cartelle diverse in un unico repository Git. In realtà, sarebbero repository diversi. Puoi utilizzare qualsiasi soluzione Git.
Cloud Build: Cloud Build è la soluzione CI di Google Cloud. Google CloudIn questo tutorial, lo utilizziamo per eseguire i test di convalida. Sebbene i dettagli dell'implementazione possano variare da un sistema CI all'altro, i concetti descritti in questo tutorial possono essere utilizzati con qualsiasi sistema CI basato su container.
Kustomize: Kustomize è uno strumento di personalizzazione per le configurazioni di Kubernetes. Funziona prendendo le configurazioni "di base" e applicando loro le personalizzazioni. Ti consente di adottare un approccio DRY (Don't Repeat Yourself) alle configurazioni di Kubernetes. Con Kustomize, mantieni gli elementi comuni a tutti gli ambienti nelle configurazioni di base e crei personalizzazioni per ambiente. In questo tutorial, manteniamo le configurazioni di Kustomize nel repository dell'app e "creiamo" (ad esempio, applichiamo le personalizzazioni) le configurazioni nella pipeline CI. Puoi utilizzare i concetti descritti in questo tutorial con qualsiasi strumento che produca configurazioni di Kubernetes pronte per essere applicate a un cluster (ad esempio, il comando helm template).
Kpt: Kpt è uno strumento per creare workflow per le configurazioni di Kubernetes. Kpt consente di recuperare, visualizzare, personalizzare, aggiornare, convalidare e applicare le configurazioni di Kubernetes. Poiché funziona con i file Git e YAML, è compatibile con la maggior parte degli strumenti esistenti dell'ecosistema Kubernetes. In questo tutorial, utilizziamo kpt nella pipeline CI per recuperare i vincoli dal repository anthos-config-management-samples e per convalidare le configurazioni di Kubernetes in base a questi vincoli.

Pipeline

La pipeline CI che utilizziamo in questo tutorial è mostrata nel seguente diagramma:

Pipeline CI per Policy Controller

La pipeline viene eseguita in Cloud Build e i comandi vengono eseguiti in una directory contenente una copia del repository dell'app di esempio. La pipeline inizia generando le configurazioni finali di Kubernetes con Kustomize. Successivamente, recupera i vincoli in base ai quali vogliamo eseguire la convalida dal repository anthos-config-management-samples utilizzando kpt. Infine, utilizza kpt per convalidare le configurazioni di Kubernetes in base a questi vincoli. Per eseguire questo ultimo passaggio, utilizziamo una funzione di configurazione specifica chiamata gatekeeper che esegue questa convalida. In questo tutorial, attivi manualmente la pipeline CI, ma in realtà la configureresti per l'esecuzione dopo un git push nel repository Git.

Obiettivi

Eseguire una pipeline CI per un'app di esempio con Cloud Build.
Osservare che la pipeline non riesce a causa di una violazione dei criteri.
Modificare il repository dell'app di esempio in modo che sia conforme ai criteri.
Eseguire di nuovo la pipeline CI.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Cloud Build
Google Kubernetes Engine

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per maggiori dettagli, consulta la sezione Eseguire la pulizia.

Prima di iniziare

Seleziona o crea un Google Cloud progetto. Nella Google Cloud console, vai a la pagina Gestisci risorse:

Vai a Gestisci risorse
Abilita la fatturazione per il tuo progetto.
Per eseguire i comandi elencati in questo tutorial, apri Cloud Shell:

Vai a Cloud Shell
In Cloud Shell, esegui gcloud config get-value project.

Se il comando non restituisce l'ID del progetto appena selezionato, configura Cloud Shell in modo che utilizzi il tuo progetto:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

In Cloud Shell, abilita l'API Cloud Build richiesta:

gcloud services enable cloudbuild.googleapis.com

Convalidare le configurazioni dell'app di esempio

In questa sezione, esegui una pipeline CI con Cloud Build per un repository di app di esempio che forniamo. Questa pipeline convalida la configurazione di Kubernetes disponibile nel repository dell'app di esempio in base ai vincoli disponibili in un repository anthos-config-management-samples.

Per convalidare le configurazioni dell'app:

In Cloud Shell, clona il repository dell'app di esempio:

git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

Esegui la pipeline CI con Cloud Build. I log della build vengono visualizzati direttamente in Cloud Shell.

cd anthos-config-management-samples/ci-app/app-repo
gcloud builds submit .

La pipeline che esegui è definita nel seguente file.

steps:
- id: 'Prepare config'
  # This step builds the final manifests for the app
  # using kustomize and the configuration files
  # available in the repository.
  name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: '/bin/sh'
  args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
- id: 'Download policies'
  # This step fetches the policies from the Anthos Config Management repository
  # and consolidates every resource in a single file.
  name: 'gcr.io/kpt-dev/kpt'
  entrypoint: '/bin/sh'
  args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git/ci-app/acm-repo/cluster@main constraints
                  && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
- id: 'Validate against policies'
  # This step validates that all resources comply with all policies.
  name: 'gcr.io/kpt-fn/gatekeeper:v0.2'
  args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']

In Policy Controller, i vincoli sono istanze di modelli di vincolo. I modelli di vincolo contengono il codice Rego effettivo utilizzato per implementare il vincolo. La funzione gcr.io/kpt-fn/gatekeeper richiede sia il modello di vincolo sia le definizioni dei vincoli per funzionare. Il repository dei criteri di esempio contiene entrambi, ma in realtà possono essere archiviati in posizioni diverse. Utilizza il comando kpt pkg get se necessario per scaricare sia i modelli di vincolo sia i vincoli.

Questo tutorial utilizza gcr.io/kpt-fn/gatekeeper con Cloud Build per convalidare le risorse, ma esistono altre due alternative che puoi utilizzare:

Utilizza la gcr.io/kpt-fn/gatekeeper funzione con kpt:

kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2

Utilizza lo gatorstrumento a riga di comando:

gator test -f hydrated-manifests/kpt-manifests.yaml

Dopo qualche minuto, osserva che la pipeline non riesce a causa del seguente errore:

[...]
Step #2 - "Validate against policies": [error] apps/v1/Deployment/nginx-deployment : Deployment objects should have an 'owner' label indicating who created them.
Step #2 - "Validate against policies": violatedConstraint: deployment-must-have-owner
Finished Step #2 - "Validate against policies"
2022/05/11 18:55:18 Step Step #2 - "Validate against policies" finished
2022/05/11 18:55:19 status changed to "ERROR"
ERROR
ERROR: build step 2 "gcr.io/kpt-fn/gatekeeper:v0.2" failed: exit status 1
2022/05/11 18:55:20 Build finished with ERROR status

Il vincolo che la configurazione sta violando è definito nel seguente file. È una risorsa personalizzata di Kubernetes chiamata K8sRequiredLabels.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: deployment-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels:
      - key: "owner"
    message: "Deployment objects should have an 'owner' label indicating who created them."

Per il modello di vincolo corrispondente a questo vincolo, consulta requiredlabels.yaml su GitHub.

Crea tu stesso la configurazione completa di Kubernetes e osserva che l'etichetta owner manca. Per creare la configurazione:
```
kubectl kustomize config/prod
```

Correggere l'app in modo che sia conforme ai criteri aziendali

In questa sezione, correggi la violazione dei criteri utilizzando Kustomize:

In Cloud Shell, aggiungi una sezione commonLabels al file di base Kustomization:

cat <<EOF >> config/base/kustomization.yaml
commonLabels:
  owner: myself
EOF

Crea la configurazione completa di Kubernetes e osserva che l'etichetta owner è ora presente:
```
kubectl kustomize config/prod
```

Esegui di nuovo la pipeline CI con Cloud Build:

gcloud builds submit .

La pipeline ora viene eseguita correttamente con il seguente output:

[...]
Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0"
Step #2 - "Validate against policies": [PASS] "gcr.io/kpt-fn/gatekeeper:v0"
[...]

Liberare spazio

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per, le attività descritte in questo documento, eliminerai anche tutto il lavoro che hai svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella Google Cloud console, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID progetto e fai clic su Chiudi per eliminare il progetto.