Validar apps en función de las políticas de la empresa en una canalización de CI

Si tu organización usa el controlador de políticas para administrar políticas en sus clústeres de la edición Enterprise de Google Kubernetes Engine (GKE), puedes validar la configuración de implementación de una app en su canalización de integración continua (CI). En este instructivo, se muestra cómo lograr este resultado. La validación de tu app es útil si eres un desarrollador que compila una canalización de CI para una app o un ingeniero de plataforma que compila una plantilla de canalización de CI para varios equipos de apps.

Las políticas son una parte importante de la seguridad y el cumplimiento de una organización. Policy Controller permite que tu organización administre esas políticas de forma centralizada y declarativa para todos tus clústeres. Como desarrollador, puedes aprovechar la naturaleza centralizada y declarativa de esas políticas. Puedes usar esas características para validar tu app en función de esas políticas lo antes posible en tu flujo de trabajo de desarrollo. Conocer los incumplimientos de política en tu canalización de CI en lugar de durante la implementación tiene dos ventajas principales: te permite aumentar las medidas de seguridad y ajusta el ciclo de reacción, lo que reduce el tiempo y el costo necesarios para corregir dichos incumplimientos.

En este instructivo, se usa Cloud Build como una herramienta de CI, y un repositorio de GitHub de muestra que contiene políticas para demostraciones.

Recursos

En este instructivo, se usan varias herramientas de Kubernetes. En esta sección, se explica qué son esas herramientas, cómo interactúan entre sí y si puedes reemplazarlas por otro elemento.

Las herramientas que usarás en este instructivo incluyen las siguientes:

  • Controlador de políticas: Se basa en el proyecto de código abierto Agente de políticas abiertas - Gatekeeper. El controlador de políticas aplica políticas sobre los objetos que se crean en un clúster de Kubernetes (por ejemplo, evita el uso de una opción específica o fuerza el uso de una etiqueta específica). Esas políticas se denominan restricciones. Las restricciones se definen como recursos personalizados de Kubernetes. Policy Controller está disponible como parte de la edición Google Kubernetes Engine (GKE) Enterprise, pero puedes usar Open Policy Agent - Gatekeeper en lugar del controlador de políticas para la implementación.

  • GitHub: En este instructivo, usamos GitHub a fin de alojar los repositorios de Git: uno para una app de muestra y otro que contiene las restricciones del controlador de políticas. Para simplificar, los dos repositorios son dos carpetas diferentes en un solo repositorio de Git. En realidad, serían repositorios diferentes. Puedes usar cualquier solución de Git.

  • Cloud Build: Es la solución de CI de Google Cloud. En este instructivo, lo usamos para ejecutar las pruebas de validación. Si bien los detalles de la implementación pueden variar de un sistema de CI a otro, los conceptos descritos en este instructivo se pueden usar con cualquier sistema de CI basado en contenedores.

  • Kustomize: Es una herramienta de personalización para la configuración de Kubernetes. Para funcionar, toma la configuración “base” y le aplica personalizaciones. Te permite tener un enfoque DRY (No te repitas) en la configuración de Kubernetes. Con Kustomize, conservas los elementos comunes a todos tus entornos en la configuración base y creas personalizaciones por entorno. En este instructivo, conservamos la configuración de Kustomize en el repositorio de la app y “compilamos” la configuración (por ejemplo, le aplicamos las personalizaciones) en la canalización de CI. Puedes usar los conceptos descritos en este instructivo con cualquier herramienta que produzca la configuración de Kubernetes lista para aplicarse a un clúster (por ejemplo, el comando helm template).

  • Kpt: Es una herramienta destinada a compilar flujos de trabajo para la configuración de Kubernetes. Kpt te permite recuperar, mostrar, personalizar, actualizar, validar y aplicar la configuración de Kubernetes. Debido a que funciona con archivos Git y YAML, es compatible con la mayoría de las herramientas existentes del ecosistema de Kubernetes. En este instructivo, usamos kpt en la canalización de CI para recuperar las restricciones del repositorio anthos-config-management-samples y validar la configuración de Kubernetes en función de esas restricciones.

Canalización

La canalización de CI que usamos en este instructivo se muestra en el siguiente diagrama:

Canalización de CI para el controlador de políticas

La canalización se ejecuta en Cloud Build y, los comandos, en un directorio que contiene una copia del repositorio de la app de muestra. La canalización comienza con la generación de la configuración final de Kubernetes mediante Kustomize. A continuación, recupera las restricciones que queremos validar en el repositorio anhos-config-management-samples mediante kpt. Por último, usa kpt para validar la configuración de Kubernetes en esas restricciones. Para lograr este último paso, usamos una función de configuración específica llamada gatekeeper que realiza esta validación. En este instructivo, activarás la canalización de CI de forma manual, pero, en realidad, la configurarás para que se ejecute después de git push en tu repositorio de Git.

Objetivos

  • Ejecutar una canalización de CI para una app de muestra mediante Cloud Build
  • Observar que la canalización falla debido a un incumplimiento de política
  • Modificar el repositorio de la app de muestra para cumplir con las políticas
  • Volver a ejecutar la canalización de CI con éxito

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

  • Cloud Build
  • Edición Google Kubernetes Engine (GKE) Enterprise

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Cuando completes el instructivo puedes borrar los recursos que hayas creado para evitar que se te sigan facturando. Para obtener más detalles, consulta la sección Realiza una limpieza.

Antes de comenzar

  1. Selecciona o crea un proyecto de Google Cloud. En la consola de Google Cloud, ve a la página Administrar recursos:

    Ir a Administrar recursos

  2. Habilita la facturación para tu proyecto.

  3. Para ejecutar los comandos enumerados en este instructivo, abre Cloud Shell:

    Ir a Cloud Shell

  4. Ejecuta gcloud config get-value project en Cloud Shell.

    Si el comando no muestra el ID del proyecto que acabas de seleccionar, configura Cloud Shell para que use tu proyecto:

    gcloud config set project PROJECT_ID
    

    Reemplaza PROJECT_ID con el ID del proyecto.

  5. En Cloud Shell, habilita la API de Cloud Build requerida:

    gcloud services enable cloudbuild.googleapis.com
    

Valida la configuración de la app de muestra

En esta sección, debes ejecutar una canalización de CI mediante Cloud Build para un repositorio de la app de muestra que proporcionamos. Esta canalización valida la configuración de Kubernetes disponible en ese repositorio de la app de muestra en función de las restricciones disponibles en un repositorio anhos-config-management-samples.

Para validar la configuración de la app, haz lo siguiente:

  1. En Cloud Shell, clona el repositorio de la app de muestra:

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    
  2. Ejecuta la canalización de CI mediante Cloud Build. Los registros de la compilación se muestran directamente en Cloud Shell.

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

    La canalización que ejecutes se define en el siguiente archivo.

    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']

    En el controlador de políticas, las restricciones son instancias de plantillas de restricción. Las plantillas de restricción contienen el código verdadero de Rego que se usa para implementar la restricción. La función gcr.io/kpt-fn/gatekeeper necesita la plantilla y las definiciones de la restricción para funcionar. El repositorio de políticas de muestra contiene ambas, pero, en realidad, puede que se almacenen en diferentes lugares. Usa el comando kpt pkg get según sea necesario para descargar las plantillas de restricción y las restricciones.

    En este instructivo, se usa gcr.io/kpt-fn/gatekeeper con Cloud Build para validar recursos, pero hay otras dos alternativas que puedes usar:

    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. Después de unos minutos, observa que la canalización falla con el siguiente error:

    [...]
    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
    

    La restricción que infringe la configuración se define en el siguiente archivo. Es un recurso personalizado de Kubernetes llamado 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."

    Para obtener la plantilla de restricción que corresponde a esta restricción, consulta requiredlabels.yaml en GitHub.

  4. Compila la configuración completa de Kubernetes y observa que falta la etiqueta owner. Para compilar la configuración, haz lo siguiente:

    kubectl kustomize config/prod
    

Corrige la app para cumplir con las políticas de la empresa

En esta sección, debes corregir el incumplimiento de políticas mediante Kustomize:

  1. En Cloud Shell, agrega una sección commonLabels al archivo Kustomization base:

    cat <<EOF >> config/base/kustomization.yaml
    commonLabels:
      owner: myself
    EOF
    
  2. Compila la configuración completa de Kubernetes y observa que la etiqueta owner ahora está presente:

    kubectl kustomize config/prod
    
  3. Vuelve a ejecutar la canalización de CI mediante Cloud Build:

    gcloud builds submit .
    

    La canalización ahora tendrá éxito y mostrará el siguiente resultado:

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

Limpia

  1. En la consola de Google Cloud, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

  • Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.