Usa el controlador de políticas en una canalización de CI

En esta página, se describe cómo integrar el controlador de políticas con Cloud Build mediante la creación de una canalización de integración continua (CI) que verifica las validaciones de políticas sincronizadas con un repositorio Git.

Introducción

Crear una canalización de CI con el controlador de políticas le permite:

Aplicar las opciones de configuración de políticas definidas y proporcionar comentarios a los desarrolladores lo antes posible. Las políticas permiten a los administradores de la plataforma bloquear el acceso. Los equipos de desarrollo deben cumplir con esas políticas en lugar de eliminarlas o eludirlas.
Establecer campos predeterminados en sus objetos Kubernetes que siempre deben estar presentes. Por ejemplo, puede agregar automáticamente etiquetas para propietarios o centros de costos.

En este documento, la información se centra en una canalización de CI de Cloud Build mediante el uso de un repositorio de configuración de GitHub. Puede usar el mismo patrón para configurar otras herramientas de CI o sistemas de control de versiones compatibles con Anthos Config Management.

Esta canalización está compilada con funciones KPT. Las funciones de KPT le permiten desarrollar imágenes de contenedor del lado del cliente para validar, transformar o generar opciones de configuración de Kubernetes.

Este tema utiliza funciones KPT preconstruidas del Catálogo de funciones KPT. Un subconjunto de las funciones del Catálogo se ha duplicado en un Container Registry compatible con Google y está disponible para todos los proyectos.

Antes de comenzar

Debes tener derecho a Anthos para instalar política de controlador con Anthos Config Management.
Necesitas un clúster con Anthos Config Management ya instalado.
Configurar el Controlador de políticas.
Tener el permiso serviceusage.services.enable en su proyecto Google Cloud y el permiso servicemanagement.services.bind en la API Cloud Build. Estos permisos son necesarios para habilitar la cuenta del servicio Cloud Build, consulte más detalles en Habilitar API.
Habilitar Cloud Build en su proyecto. Esto se puede hacer a través de la Google Cloud Console.

Usar un repositorio no estructurado

En este instructivo, se incluye la opción de usar un repositorio no estructurado. Los repositorios no estructurados no requieren la estructura de directorio de Anthos Config Management predeterminada.

Configura Cloud Build

Debe otorgar la función de "Desarrollador de Kubernetes Engine" a la cuenta del servicio Cloud Build en cada proyecto donde configure la canalización.

Abrir la página Configuración (Settings) de Cloud Build

Aparece la página Permisos de cuenta de servicio.
Busque la fila que contiene Kubernetes Engine y establezca el Estado en Habilitado.

Para obtener más información, consulte Configuración de permisos de cuenta de servicio.

Configura tu entorno

Para configurar el controlador de políticas para que funcione con Cloud Build, consulte el ejemplo de repositorio de Git.

Clone el repositorio con git.

git clone git@github.com:GoogleCloudPlatform/csp-config-management.git

Si está utilizando un repositorio jerárquico, debe editar los archivos de configuración en este repositorio después de configurar Cloud Build.

Estructura del directorio

En el repositorio csp-config-management, hay dos directorios que contienen opciones de configuración para un repositorio jerárquico (ci-pipeline/) y un repositorio no estructurado (ci-pipeline-unstructured/). Elija el directorio apropiado para su tipo de clúster.

Los directorios ci-pipeline/ y ci-pipeline-unstructured/ en el repositorio usan la siguiente jerarquía:

config-root/ es la raíz del repositorio y contiene todas las opciones de configuración para este ejemplo.
config-root/.../*-constraint.yaml y *-template.yaml definen las restricciones y las plantillas del Controlador de políticas que deben pasar todas las opciones de configuración en config-root/.

Por ejemplo:
- El archivo ci-pipeline/config-root/cluster/required-labels-constraint.yaml requiere que cada espacio de nombres debe tener una etiqueta cost-center.
- El archivo ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml exige que ningún Objeto de ConfigMap contenga un campo llamado private-key.
Para obtener más información, consulte Crea restricciones.
cloudbuild.yaml es el archivo de configuración de Cloud Build que define los pasos de compilación. Estos pasos de compilación son activados por una confirmación en el repositorio.

Si usas un repositorio jerárquico, la canalización construye el contenido del repositorio con nomos hydrate, los concatena y los valida con el controlador de políticas.

En un repositorio no estructurado, el controlador de políticas crea la configuración sin utilizar nomos ni conectarse al clúster.

Para obtener más información sobre el contenido de un archivo de configuración, consulte Crear una configuración básica.

Configura Cloud Build

En esta sección, conectará Cloud Build a su repositorio de origen para que Cloud Build pueda compilar el código en ese repositorio.

Crea un activador de compilación

Cloud Build ejecuta activadores de compilación cuando se envía una confirmación a la rama. Para configurar un activador de compilación en Google Cloud Console, realice los siguientes pasos.

Abre la página Activadores en Google Cloud Console.

Abrir la página Activadores
Selecciona tu proyecto en el menú desplegable del selector de proyectos en la parte superior de la página.
Haz clic en Abrir.
Haz clic en Crear activador.
Crea un Nombre para el activador.
Para Evento, selecciona Enviar a una rama.
Selecciona el Repositorio. Si conectaste el repositorio, completa los siguientes pasos:
1. Haz clic en Conectar repositorio.
2. Selecciona el repositorio en el que almacenaste el código fuente.
  
  Si selecciona GitHub (duplicado) o Bitbucket (duplicado) como su repositorio de origen, Cloud Build duplica su repositorio en Cloud Source Repositories y utiliza el repositorio duplicado.
3. Haga clic en Continue.
4. Autentica el repositorio de código fuente con tu nombre de usuario y contraseña.
5. En la lista de repositorios disponibles, selecciona el repositorio que deseas y, luego, haz clic en Conectar repositorio.
De la lista de repositorios disponibles, seleccione el repositorio csp-config-management.
Seleccione su rama, master.
Nota: Las compilaciones solo se inician cuando ingresa al repositorio remoto, y no en cambios locales, envíos previos o solicitudes de extracción.
En Configuración de compilación, configure su Archivo de configuración de Cloud Build como ci-pipeline/cloudbuild.yaml o ci-pipeline-unstructured/cloudbuild.yaml.
Haz clic en Crear para guardar el activador de compilación.

También puede crear activadores de compilación con gcloud. Para obtener más información, consulte Crear y administrar activadores de compilación.

Configura tu repositorio

Después de configurar Cloud Build para conectarse a su repositorio, complete la configuración para Anthos Config Management.

Edite el archivo csp-config-management/CODEOWNERS y reemplace @OWNER con su nombre de usuario GitHub o el alias de correo electrónico del equipo de administración de la plataforma. Para obtener más información sobre la sintaxis de CODEOWNERS, consulte Acerca de los propietarios de códigos.

Seleccione si está utilizando un repositorio jerárquico (predeterminado) o no estructurado a continuación.

Edita el archivo de configuración

Jerárquico
Edita el archivo csp-config-management/ci-pipeline/cloudbuild.yaml.

Reemplace CLUSTER_NAME y ZONE con el nombre del clúster y la zona de un clúster GKE con Anthos Config Management y el controlador de políticas instalados.

No estructurado
No es necesario cambiar la configuración con un repositorio no estructurado en este ejemplo. Anthos Config Management y el controlador de políticas validan su repositorio sin conectarse a su clúster.
Agregue y confirme sus cambios al repositorio.
Jerárquico
```
cd ci-pipeline
git add .
git commit -m "[COMMIT_MESSAGE]"
```
No estructurado
```
cd ci-pipeline-unstructured
git add .
git commit -m "[COMMIT_MESSAGE]"
```
Después de la confirmación, Cloud Build ejecuta una validación de política en el repositorio.
Abra su Historial de Cloud Build y haga clic en la compilación más reciente.

Se mostrará la página Detalles de compilación.
La muestra en el repositorio csp-config-management contiene un error.

Seleccione la compilación más reciente de la parte superior de la lista, que incluye el icono .

El último paso que ejecuta Cloud Build termina con un error. El error sigue.

Jerárquico

Error: Found 1 violations:
[1] All namespaces must have a cost-center label that points to your division
name: "shipping-prod"
path: namespace_shipping-prod.yaml

No estructurado

Step #2: Error: Found 1 violations:
[1] The following banned keys are being used in the config map: {"private_key"}
name: "super-secret"
path: configmap.yaml

A continuación, edita un archivo en el repositorio para corregir el error.
Jerárquico
Edite el archivo /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml y establezca un valor para metadata.labels.cost-center. Su namespace.yaml debería tener el siguiente aspecto:
```
apiVersion: v1
kind: Namespace
metadata:
  name: shipping-prod
  labels:
    env: prod
    cost-center: "shipping.foo-corp.com"
  annotations:
    audit: "true"
```
No estructurado
Edita el archivo /ci-pipeline-unstructured/config-root/configmap.yaml. Cambie el campo llamado data.private_key a data.public_key. Su YAML editado se parece a lo siguiente.
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: super-secret
  namespace: default
data:
  public_key: no secrets here
```
Luego, confirma y aplica los cambios.
```
git add .
git commit -m "[COMMIT_MESSAGE]"
git push origin [BRANCH]
```
Abra su Historial de Cloud Build y haga clic en la compilación más reciente.

Se mostrará la página Detalles de compilación.
Su nueva compilación debería ser Exitosa.

Soluciona problemas

Problema: la compilación de Cloud Build falla y el historial incluye el siguiente error.

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

Solución: Confirme su instalación del Controlador de políticas.

¿Qué sigue?

Lea sobre Crear restricciones con el controlador de políticas.
Obtenga más información sobre Crear y administrar activadores de compilación con Cloud Build.