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

Si la organización usa Anthos Config Management y el controlador de políticas para administrar políticas en sus clústeres de Anthos, 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. El controlador de políticas, que forma parte de Anthos Config Management, permite que tu organización administre esas políticas de manera centralizada y declarativa para todos los 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.

Si tienes el control de Anthos Config Management y del controlador de políticas, y deseas compilar una canalización de CI para ellos (y no para una app específica), consulta Usa el controlador de políticas en una canalización de CI.

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: El controlador de políticas es un producto de Google Cloud que forma parte de Anthos Config Management. 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. Sincronizador de configuración: Te permite declarar esas restricciones en un repositorio de Git y aplicar flujos de trabajo de desarrollo tradicionales al proceso de administración de políticas. El sincronizador de configuración está disponible como un producto independiente y como parte de Anthos Config Management. Puedes usar el agente de políticas abiertas: Gatekeeper, en lugar del controlador de políticas, para tu implementación.

  • GitHub: En este instructivo, usamos GitHub con el fin de alojar los repositorios de Git, uno para una app de muestra, y otro para Anthos Config Management (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 de Anthos Config Management y validar la configuración de Kubernetes en 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 función del repositorio de Anthos Config Management 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-validate 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

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 Google Cloud Console, 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 por 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 de muestra de Anthos Config Management.

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@1.0.0 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/config-management-release/policy-controller-validate'
      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.

  3. Después de unos minutos, observa que la canalización falla con el siguiente error:

    [...]
    Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0"
    Step #2 - "Validate against policies": [FAIL] "gcr.io/kpt-fn/gatekeeper:v0"
    Step #2 - "Validate against policies":   Results:
    Step #2 - "Validate against policies":     [ERROR] Deployment objects should have an 'owner' label indicating who created them. violatedConstraint: deployment-must-have-owner in object "apps/v1/Deployment/nginx-deployment" in file "prod.yaml"
    Step #2 - "Validate against policies":   Stderr:
    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"
    Step #2 - "Validate against policies":     ""
    Step #2 - "Validate against policies":   Exit code: 1
    [...]
    

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

Realiza una limpieza

  1. En Cloud Console, 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.

Próximos pasos