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.

Si eres un desarrollador y deseas validar tu app según las políticas de la empresa, consulta Valida tu app según las políticas de la empresa en una canalización de integración continua en su lugar.

Introducción

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

Aplicar configuraciones 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. Luego, los equipos de desarrollo deben cumplir con esas políticas, en lugar de quitarlas o eludirlas.
Configurar campos predeterminados en tus objetos de Kubernetes que siempre deberían estar presentes. Por ejemplo, puedes agregar etiquetas automáticamente a los propietarios o al centro de costos.

Este documento se centra en una canalización de CI de Cloud Build mediante el uso de un repositorio de configuración de GitHub. Puedes usar el mismo patrón para configurar otras herramientas de CI u otros sistemas de control de versión 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.

En este tema, se usan funciones de KPT compiladas de forma previa provenientes del catálogo de funciones de KPT. Se duplicó un subconjunto de las funciones del catálogo en un Container Registry compatible con Google, y está disponible para todos los proyectos.

Antes de comenzar

Debes tener autorización de Anthos para instalar el controlador de políticas mediante Anthos Config Management.
Necesitas un clúster con Anthos Config Management ya instalado.
Configurar el Controlador de políticas.
Debes tener el permiso serviceusage.services.enable en tu proyecto de Google Cloud y el permiso servicemanagement.services.bind en la API de Cloud Build. Estos permisos son necesarios para habilitar la cuenta de servicio de Cloud Build. Obtén más detalles en Habilita API.
Debes habilitar Cloud Build en tu proyecto. Esto se puede hacer a través de 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

Aparecerá la página Permisos de la cuenta de servicio.
Busca la fila que contiene Kubernetes Engine y configura el Estado como Habilitado.

Para obtener más información, consulta Configura los permisos de la 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.

Clona el repositorio con git.

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

Si usas un repositorio jerárquico, debes 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/ del 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 tenga una etiqueta cost-center.
- El archivo ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml garantiza que ningún objeto 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 se activan mediante 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, consulta Crea una configuración básica.

Configura Cloud Build

En esta sección, debes conectar Cloud Build con tu 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.
En la lista de los repositorios disponibles, selecciona 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.

Edita el archivo csp-config-management/CODEOWNERS y reemplaza @OWNER por tu nombre de usuario de 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, consulta Información acerca de CODEOWNERS.

Selecciónalo si estás usando un repositorio jerárquico (predeterminado) o el siguiente repositorio sin estructurar.

Edita el archivo de configuración

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

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

No estructurado
No se necesita realizar ningún cambio en la configuración si se usa un repositorio sin estructurar en este ejemplo. Anthos Config Management y el controlador de políticas validan tu repositorio sin conectarse a tu clúster.
Agrega y confirma los cambios en el 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íticas 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.

Selecciona la compilación más reciente en la parte superior de la lista, en la que se incluye el ícono de .

El último paso que ejecuta Cloud Builds finaliza con un error. A continuación, se indica el error.

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
Edita el archivo /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml y establece un valor para metadata.labels.cost-center. Tu archivo namespace.yaml debería verse de la siguiente manera:
```
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. Cambia el campo llamado data.private_key a data.public_key. El YAML editado es similar al siguiente ejemplo.
```
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.
La compilación nueva debe ser Correcta.

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: Confirma la instalación del controlador de políticas.

¿Qué sigue?

Lea sobre Crear restricciones con el controlador de políticas.
Obtén más información sobre cómo validar tu app en función de las políticas de la empresa en una canalización de CI.
Obtenga más información sobre Crear y administrar activadores de compilación con Cloud Build.