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

Se la tua organizzazione utilizza Policy Controller per gestire nei cluster della versione Google Kubernetes Engine (GKE) Enterprise, poi potrai convalidare configurazione del deployment nella sua pipeline di integrazione continua (CI). Questo il tutorial mostra come ottenere questo risultato. La convalida dell'app è utile gli sviluppatori che creano una pipeline CI per un'app o i platform creando un modello di pipeline CI per più team dedicati alle app.

I criteri sono una parte importante della sicurezza e della conformità di un dell'organizzazione. Policy Controller consente della tua organizzazione di gestire questi criteri a livello centrale e dichiarativo per tutti cluster. In qualità di sviluppatore, puoi sfruttare le funzionalità natura dichiarativa di tali norme. Puoi utilizzare queste caratteristiche per di convalidare la tua app in base a queste norme il prima possibile nei un flusso di lavoro di sviluppo. Informazioni sulle violazioni delle norme nella pipeline CI anziché durante la distribuzione presenta due vantaggi principali: consente la sicurezza e questo restringe il ciclo di feedback, riducendo i tempi e i costi necessari correggere tali violazioni.

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

Risorse

Questo tutorial utilizza diversi strumenti Kubernetes. Questa sezione spiega che cosa e come interagiscono tra loro e se è possibile 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 che vengono creati in un Cluster Kubernetes (ad esempio, impedendo l'utilizzo di un'opzione specifica o l'applicazione forzata dell'utilizzo di un'etichetta specifica). Questi criteri sono chiamati vincoli. I vincoli sono definiti come risorse personalizzate di Kubernetes. Policy Controller è disponibile come parte della versione Google Kubernetes Engine (GKE) Enterprise, ma puoi utilizza 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 di esempio e una che contiene i vincoli per Policy Controller. Per semplicità, i due repository sono due in un singolo repository Git. In realtà, sarebbero diversi repository. Puoi utilizzare qualsiasi soluzione Git.

  • Cloud Build: Cloud Build è la soluzione CI di Google Cloud. In questo tutorial utilizziamo per eseguire i test di convalida. Sebbene i dettagli dell'implementazione possano variano da un sistema CI all'altro, i concetti descritti in questo tutorial può essere utilizzato con qualsiasi sistema CI basato su container.

  • Kustomize: Kustomize è uno strumento di personalizzazione per le configurazioni di Kubernetes. Funziona prendendo "base" configurazioni e la relativa personalizzazione. Ti permette di avere un approccio DRY (non ripetere) alle configurazioni di Kubernetes. Con Kustomize, gli elementi comuni a tutti gli ambienti vengono mantenuti nelle configurazioni di base e creare personalizzazioni per ambiente. In questo tutorial, tratteremo Kustomize le configurazioni nel repository di app e "creiamo" (ad esempio, applica il parametro (personalizzazioni)) le configurazioni nella pipeline CI. Puoi utilizzare i concetti descritti in questo tutorial con qualsiasi strumento che generi configurazioni Kubernetes. pronte per essere applicate a un cluster (ad esempio, helm template).

  • Kpt: Kpt è uno strumento per la creazione di flussi di lavoro per le configurazioni Kubernetes. Kpt consente di recuperare, visualizzare, personalizzare, aggiornare, convalidare e applicare configurazioni di Kubernetes. Poiché funziona con file Git e YAML, è compatibile con la maggior parte dei gli strumenti esistenti dell'ecosistema Kubernetes. In questo tutorial, utilizziamo kpt la pipeline CI per recuperare i vincoli dal repository anthos-config-management-samples, e convalidare le configurazioni Kubernetes a fronte di questi vincoli.

Pipeline

La pipeline CI utilizzata 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 un contenente una copia del repository di app di esempio. La pipeline viene avviata generando le configurazioni Kubernetes finali con Kustomize. Poi, recupera i vincoli in base ai quali eseguire la convalida repository anthos-config-management-samples utilizzando kpt. Infine, utilizza kpt per convalidare le configurazioni di Kubernetes rispetto a questi vincoli. Per raggiungere quest'ultimo passaggio, usiamo una specifica funzione di configurazione denominata gatekeeper che esegue questa convalida. In questo tutorial, attiverai la pipeline CI manualmente, ma in realtà dovresti configurarla per essere eseguita dopo un git push nel tuo repository Git.

Obiettivi

  • Eseguire una pipeline CI per un'app di esempio con Cloud Build.
  • Osserva che la pipeline non funziona a causa di una violazione delle norme.
  • Modifica il repository di app di esempio in modo che rispetti le norme.
  • Esegui di nuovo la pipeline CI.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

  • Cloud Build
  • Versione Google Kubernetes Engine (GKE) Enterprise

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza Calcolatore prezzi.

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando il le risorse che hai creato. Per ulteriori dettagli, consulta Pulizia .

Prima di iniziare

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

    Vai a Gestisci risorse

  2. Attiva la fatturazione per il progetto.

  3. Per eseguire i comandi elencati in questo tutorial, apri Cloud Shell:

    Vai a Cloud Shell

  4. Esegui gcloud config get-value project in Cloud Shell.

    Se il comando non restituisce l'ID del progetto appena selezionato, configura Cloud Shell per utilizzare il tuo progetto:

    gcloud config set project PROJECT_ID
    

    Sostituisci PROJECT_ID con l'ID progetto.

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

    gcloud services enable cloudbuild.googleapis.com
    

Convalida le configurazioni dell'app di esempio

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

Per convalidare le configurazioni dell'app:

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

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    
  2. Eseguire la pipeline CI con Cloud Build. Vengono visualizzati i log della build direttamente in Cloud Shell.

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

    La pipeline che esegui è definita nel file di seguito.

    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 un vincolo modelli di machine learning. I modelli di vincolo contengono Il codice Rego utilizzato per implementare la classe. di blocco. gcr.io/kpt-fn/gatekeeper richiede sia il modello di vincolo sia le definizioni del vincolo al lavoro. Il repository di criteri di esempio contiene entrambi, ma in realtà possono essere archiviati in posizioni diverse. Usa il comando kpt pkg get in base alle esigenze scaricare sia i modelli che i vincoli.

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

    kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2
    
    gator test -f hydrated-manifests/kpt-manifests.yaml
    
  3. Dopo alcuni minuti, osserva che la pipeline ha esito negativo e restituisce il 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 modo: . È 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, vedi requiredlabels.yaml su GitHub.

  4. Crea autonomamente la configurazione completa di Kubernetes e osserva che Manca l'etichetta owner. Per creare la configurazione:

    kubectl kustomize config/prod
    

Correggi l'app per renderla conforme alle norme aziendali

In questa sezione, correggerai la violazione delle norme utilizzando Kustomize:

  1. In Cloud Shell, aggiungi una sezione commonLabels alla base File di Kustomization:

    cat <<EOF >> config/base/kustomization.yaml
    commonLabels:
      owner: myself
    EOF
    
  2. Crea la configurazione completa di Kubernetes e osserva che l'etichetta owner è ora presente:

    kubectl kustomize config/prod
    
  3. Esegui di nuovo la pipeline CI con Cloud Build:

    gcloud builds submit .
    

    La pipeline ora riesce 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"
    [...]
    

Esegui la pulizia

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi