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 permisoservicemanagement.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 enconfig-root/
.Por ejemplo:
El archivo
ci-pipeline/config-root/cluster/required-labels-constraint.yaml
requiere que cada espacio de nombres tenga una etiquetacost-center
.El archivo
ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml
garantiza que ningún objeto ConfigMap contenga un campo llamadoprivate-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.
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:
Haz clic en Conectar repositorio.
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.
Haga clic en Continue.
Autentica el repositorio de código fuente con tu nombre de usuario y contraseña.
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
.En Configuración de compilación, configure su Archivo de configuración de Cloud Build como
ci-pipeline/cloudbuild.yaml
oci-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.yamlNo 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 parametadata.labels.cost-center
. Tu archivonamespace.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 llamadodata.private_key
adata.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.