Esta página se ha traducido con Cloud Translation API.

Validar aplicaciones según las políticas de la empresa en un flujo de procesamiento de integración continua

Si tu organización usa Policy Controller para gestionar políticas en sus clústeres de Google Kubernetes Engine, puedes validar la configuración de despliegue de una aplicación en su flujo de procesamiento de integración continua (CI). En este tutorial se muestra cómo conseguir este resultado. Validar tu aplicación es útil si eres desarrollador y estás creando un flujo de procesamiento de integración continua para una aplicación, o si eres ingeniero de plataformas y estás creando una plantilla de flujo de procesamiento de integración continua para varios equipos de aplicaciones.

Esta página está dirigida a administradores y operadores de TI que quieran asegurarse de que todos los recursos que se ejecutan en la plataforma en la nube cumplen los requisitos de cumplimiento de la organización proporcionando y manteniendo la automatización para auditar o aplicar, y que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE.Google Cloud

Las políticas son una parte importante de la seguridad y el cumplimiento de una organización. Policy Controller permite a tu organización gestionar esas políticas de forma centralizada y declarativa en 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 aplicación con respecto a esas políticas lo antes posible en tu flujo de trabajo de desarrollo. Si detectas las infracciones de las políticas en tu canalización de integración continua en lugar de durante la implementación, obtendrás dos ventajas principales: podrás desplazar la seguridad hacia la izquierda y acortar el bucle de comentarios, lo que reducirá el tiempo y el coste necesarios para corregir esas infracciones.

En este tutorial se usa Cloud Build como herramienta de integración continua y un repositorio de GitHub de ejemplo que contiene políticas para demostraciones.

Recursos

En este tutorial 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 sustituirlas por otras.

Las herramientas que usarás en este tutorial son las siguientes:

Policy Controller: se basa en el proyecto de código abierto Open Policy Agent - Gatekeeper. Policy Controller aplica políticas sobre los objetos que se crean en un clúster de Kubernetes (por ejemplo, impide el uso de una opción específica o fuerza el uso de una etiqueta específica). Estas políticas se denominan restricciones. Las restricciones se definen como recursos personalizados de Kubernetes. Policy Controller está disponible como parte de GKE, pero puedes usar Open Policy Agent - Gatekeeper en lugar de Policy Controller para tu implementación.
GitHub en este tutorial, usamos GitHub para alojar los repositorios de Git: uno para una aplicación de muestra y otro que contiene las restricciones de Policy Controller. Para simplificar, los dos repositorios son dos carpetas diferentes en un único repositorio de Git. En realidad, serían repositorios diferentes. Puedes usar cualquier solución de Git.
Cloud Build: Cloud Build es la solución de CI de Google Cloud. En este tutorial, la usaremos para ejecutar las pruebas de validación. Aunque los detalles de la implementación pueden variar de un sistema de integración continua a otro, los conceptos descritos en este tutorial se pueden usar con cualquier sistema de integración continua basado en contenedores.
Kustomize: Kustomize es una herramienta de personalización para las configuraciones de Kubernetes. Funciona tomando configuraciones "base" y aplicándoles personalizaciones. Te permite adoptar un enfoque DRY (Don't Repeat Yourself) para las configuraciones de Kubernetes. Con Kustomize, puedes mantener los elementos que son comunes a todos tus entornos en las configuraciones base y crear personalizaciones por entorno. En este tutorial, mantendremos las configuraciones de Kustomize en el repositorio de la aplicación y "compilaremos" (por ejemplo, aplicaremos las personalizaciones) las configuraciones en la canalización de CI. Puedes usar los conceptos descritos en este tutorial con cualquier herramienta que genere configuraciones de Kubernetes listas para aplicarse a un clúster (por ejemplo, el comando helm template).
Kpt: Kpt es una herramienta para crear flujos de trabajo de configuraciones de Kubernetes. Kpt te permite obtener, mostrar, personalizar, actualizar, validar y aplicar configuraciones de Kubernetes. Como funciona con archivos Git y YAML, es compatible con la mayoría de las herramientas del ecosistema de Kubernetes. En este tutorial, usamos kpt en la canalización de CI para obtener las restricciones del repositorio anthos-config-management-samples y para validar las configuraciones de Kubernetes con esas restricciones.

Flujo de procesamiento

El flujo de procesamiento de CI que usamos en este tutorial se muestra en el siguiente diagrama:

Flujo de procesamiento de CI para Policy Controller

La canalización se ejecuta en Cloud Build y los comandos se ejecutan en un directorio que contiene una copia del repositorio de la aplicación de ejemplo. El flujo de procesamiento empieza generando las configuraciones finales de Kubernetes con Kustomize. A continuación, obtiene las restricciones con las que queremos validar desde el repositorio anthos-config-management-samples mediante kpt. Por último, usa kpt para validar las configuraciones de Kubernetes con respecto a esas restricciones. Para llevar a cabo este último paso, usamos una función de configuración específica llamada gatekeeper, que realiza esta validación. En este tutorial, activas el flujo de procesamiento de CI manualmente, pero en realidad lo configurarías para que se ejecute después de un git push en tu repositorio de Git.

Objetivos

Ejecuta un flujo de procesamiento de CI para una aplicación de ejemplo con Cloud Build.
Observa que la canalización falla debido a una infracción de las políticas.
Modifica el repositorio de la aplicación de ejemplo para que cumpla las políticas.
Vuelve a ejecutar la canalización de CI correctamente.

Costes

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

Cloud Build
Google Kubernetes Engine

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Cuando termines este tutorial, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpieza.

Antes de empezar

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

Ir a Gestionar recursos
Habilita la facturación de tu proyecto.
Para ejecutar los comandos que se indican en este tutorial, abre Cloud Shell:

Ir a Cloud Shell
En Cloud Shell, ejecuta gcloud config get-value project.

Si el comando no devuelve el ID del proyecto que acabas de seleccionar, configura Cloud Shell para que use tu proyecto:
```
gcloud config set project PROJECT_ID
```
Sustituye PROJECT_ID por el ID del proyecto.
En Cloud Shell, habilita la API de Cloud Build necesaria:
```
gcloud services enable cloudbuild.googleapis.com
```

Validar las configuraciones de la aplicación de ejemplo

En esta sección, ejecutarás una canalización de integración continua con Cloud Build para un repositorio de aplicaciones de ejemplo que te proporcionamos. Esta canalización valida la configuración de Kubernetes disponible en ese repositorio de aplicaciones de ejemplo con las restricciones disponibles en un repositorio de anthos-config-management-samples.

Para validar las configuraciones de la aplicación, haz lo siguiente:

En Cloud Shell, clona el repositorio de la aplicación de ejemplo:

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

Ejecuta la canalización de integración continua con 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 ejecutas 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 Policy Controller, las restricciones son instanciaciones de plantillas de restricciones. Las plantillas de restricciones contienen el código Rego real que se usa para implementar la restricción. La función gcr.io/kpt-fn/gatekeeper necesita tanto la plantilla de restricción como las definiciones de restricción para funcionar. El repositorio de políticas de ejemplo contiene ambos, pero en realidad se pueden almacenar en lugares diferentes. Usa el comando kpt pkg get según sea necesario para descargar tanto las plantillas de restricciones como las restricciones.

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

Usa la función gcr.io/kpt-fn/gatekeeper con kpt:

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

Usa la herramienta de línea de comandos gator:

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

Al cabo de unos minutos, observa que la canalización falla y muestra 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. Se trata de 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 ver la plantilla de restricción correspondiente a esta restricción, consulta requiredlabels.yaml en GitHub.

Crea tú mismo la configuración completa de Kubernetes y observa que falta la etiqueta owner. Para crear la configuración:
```
kubectl kustomize config/prod
```

Corregir la aplicación para que cumpla las políticas de la empresa

En esta sección, corregirá la infracción de la política con Kustomize:

En Cloud Shell, añade una sección commonLabels al archivo Kustomization base:

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

Crea la configuración completa de Kubernetes y observa que la etiqueta owner ahora está presente:
```
kubectl kustomize config/prod
```

Vuelve a ejecutar la canalización de CI con Cloud Build:

gcloud builds submit .

Ahora, la canalización se completa correctamente con 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"
[...]

Limpieza

Precaución: Eliminar un proyecto tiene los siguientes efectos:

Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.

Si tienes previsto consultar varias arquitecturas, tutoriales o guías de inicio rápido, reutilizar los proyectos puede ayudarte a no superar los límites de cuota de proyectos.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.