Migra desde Policy Controller

En este documento, se explica cómo migrar tus políticas de admisión desde Policy Controller para reducir el riesgo de que se produzcan brechas en la aplicación de las políticas. Policy Controller dejará de estar disponible a partir del 12 de noviembre de 2026 y dejará de recibir asistencia el 31 de diciembre de 2027. En la versión 1.39 y posteriores, los clústeres de Google Kubernetes Engine (GKE) no admiten Policy Controller.

Puedes migrar las políticas de admisión que aplicas con Policy Controller a ValidatingAdmissionPolicies de Kubernetes o a Open Policy Agent (OPA) Gatekeeper autoadministrado. La migración no afecta las cargas de trabajo que ya se están ejecutando. Policy Controller evalúa las solicitudes para crear o actualizar recursos, por lo que quitarlo no reinicia ni cambia las cargas de trabajo en ejecución.

Este documento está dirigido a operadores y especialistas en seguridad que administran Policy Controller en una flota. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes del usuario de GKE.

Actualizaciones bloqueadas a la versión 1.39 de GKE

GKE bloquea las actualizaciones a la versión 1.39 y posteriores para los clústeres que tienen instalado Policy Controller. Antes de actualizar un clúster a la versión 1.39, migra tus políticas y quita Policy Controller de ese clúster. No quites Policy Controller solo para desbloquear la actualización antes de migrar tus políticas, ya que, si lo haces, el clúster quedará sin aplicación de políticas.

Elige un reemplazo

Evalúa cada política de admisión en Policy Controller y elige una opción de reemplazo para esa política de la siguiente tabla. No es necesario que elijas un reemplazo para todo un clúster. Puedes combinar opciones en el mismo clúster según lo que requiera cada política:

Comparación de las opciones de reemplazo de Policy Controller
Opción Cuándo usar Operación y asistencia
ValidatingAdmissionPolicy (recomendado) Son políticas que verifican un solo recurso cuando se crea o actualiza. La mayoría de las plantillas de la biblioteca de plantillas de Policy Controller funcionan de esta manera. Las ValidatingAdmissionPolicies están integradas en Kubernetes y disponibles en GKE 1.30 y versiones posteriores sin costo adicional. La Atención al cliente de Cloud admite ValidatingAdmissionPolicies como parte de GKE.
Admisión de seguridad de Pods (recomendada para paquetes de seguridad de Pods) Controles de seguridad de Pods predefinidos de los paquetes pss-baseline-v2022, pss-restricted-v2022 o psp-v2022. Para obtener más información, consulta Usa la admisión de seguridad de Pods para los paquetes de seguridad de Pods. La admisión de seguridad de Pods está integrada en Kubernetes y habilitada de forma predeterminada en GKE sin costo adicional. La Atención al cliente admite la admisión de seguridad de Pods como parte de GKE.
OPA Gatekeeper autoadministrado Políticas que ValidatingAdmissionPolicies no puede expresar, como políticas de referencia que leen otros recursos del clúster, políticas que deseas mantener en Rego y auditorías de recursos existentes. También puedes agregar reglas de Common Expression Language (CEL) a las ConstraintTemplates de Gatekeeper para que este genere ValidatingAdmissionPolicies para la aplicación de políticas del servidor de la API, y su controlador de auditoría verifique los recursos existentes. Instalas, actualizas y operas Gatekeeper. El equipo de Atención al cliente no admite Gatekeeper de código abierto. La comunidad de Gatekeeper proporciona asistencia a través de GitHub.

Inventariar y clasificar tus políticas

De forma predeterminada, la biblioteca de plantillas de Policy Controller instala todas las plantillas, y los paquetes de políticas instalan sus restricciones con la medida por incumplimiento dryrun. Como resultado, las plantillas y las restricciones de un clúster no coinciden necesariamente con las políticas que aplicas. Para averiguar qué aplicas, sigue estos pasos:

  1. Identifica los clústeres de tu flota que ejecutan Policy Controller:

    gcloud container fleet policycontroller describe \
    --project=PROJECT_ID

    Reemplaza PROJECT_ID por el ID del proyecto host de tu flota.

  2. En cada clúster que identificaste, enumera tus restricciones:

    kubectl get constraints \
    -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'

    En el resultado, se muestra la medida por incumplimiento de cada restricción, su recuento de incumplimientos de la auditoría más reciente y cualquier paquete que la haya instalado. Una restricción que no tiene valor en la columna ACTION usa la medida por incumplimiento deny predeterminada.

  3. Crea una copia de seguridad de tus ConstraintTemplates y restricciones en archivos separados:

    kubectl get constrainttemplates -o yaml \
    > policy-controller-templates-backup.yaml
kubectl get constraints -o yaml \
    > policy-controller-constraints-backup.yaml

  4. Opcional: Realiza las siguientes operaciones de copia de seguridad adicionales:

    • Si habilitaste las reglas de referencia en Policy Controller, crea una copia de seguridad de tu configuración de sincronización:

      kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
    > policy-controller-config-backup.yaml

    • Si habilitaste la mutación en Policy Controller, crea una copia de seguridad de tus mutadores:

      kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
    > policy-controller-mutators-backup.yaml

Guarda estos archivos de copia de seguridad en un lugar seguro. Cuando quitas Policy Controller, se borran todas las ConstraintTemplates, restricciones, configuraciones de sincronización y mutadores del clúster, incluidos los que creaste. Necesitas las copias de seguridad para traducir o volver a crear tus políticas.

Después de crear una copia de seguridad de tus políticas, determina la ruta de migración para cada restricción. Para ello, verifica el tipo de restricción en la siguiente tabla:

Rutas de migración por tipo de restricción
Tipo de restricción Ruta de migración
Restricción de un solo recurso Si una restricción evalúa campos solo en el recurso entrante sin leer data.inventory ni pertenecer a un paquete de seguridad de Pod, usa una ValidatingAdmissionPolicy.
Restricción dryrun no aplicada Si una restricción usa la medida por incumplimiento dryrun y no planeas aplicarla, bórrala.
Restricción del paquete de seguridad de Pods Si una restricción proviene del paquete pss-baseline-v2022, pss-restricted-v2022 o psp-v2022, usa la admisión de seguridad de Pods. Usa ValidatingAdmissionPolicies para cualquier control que no abarque la admisión de seguridad de Pods.
Restricción referencial Si una restricción usa una plantilla referencial que lee otros recursos en el clúster, usa Gatekeeper autoadministrado. Para encontrar plantillas referenciales, busca la referencia data.inventory en tu archivo de copia de seguridad.
Restricción de Cloud Service Mesh, Istio o Google Cloud Revisa la restricción de forma individual para verificar si una función integrada de GKE reemplaza la política o si la ConstraintTemplate en tu archivo de copia de seguridad lee data.inventory. La mayoría de estas plantillas solo verifican el recurso entrante y funcionan en ValidatingAdmissionPolicies, excepto las plantillas referenciales AsmAuthzPolicyDefaultDeny y AsmPeerAuthnMeshStrictMtls, que requieren Gatekeeper autoadministrado. Para los reemplazos integrados, habilita la Autorización Binaria en lugar de usar la ConstraintTemplate K8sRequireBinAuthZ y configura la imagen de nodo de tus grupos de nodos en lugar de usar la ConstraintTemplate K8sRequireCosNodeImage.

Migra a ValidatingAdmissionPolicy

Un ValidatingAdmissionPolicy contiene la lógica de la política, como una ConstraintTemplate. Un ValidatingAdmissionPolicyBinding aplica la política, como una restricción. Un ValidatingAdmissionPolicy usa expresiones de CEL en lugar de Rego, y el servidor de la API evalúa las expresiones directamente, sin un webhook.

Ejemplo: Repositorios de imágenes permitidos

La siguiente restricción de Policy Controller requiere que los Pods usen imágenes de un repositorio de Artifact Registry. Excluye el espacio de nombres kube-system:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

Los siguientes ValidatingAdmissionPolicy y ValidatingAdmissionPolicyBinding aplican la misma regla. ValidatingAdmissionPolicyBinding usa las acciones Warn y Audit para que puedas comparar los resultados antes de aplicar ValidatingAdmissionPolicy:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

En este ejemplo, la variable repos contiene el valor del campo parameters de la restricción. La expresión de validación muestra un valor true para los Pods que cumplen con la ValidatingAdmissionPolicy, que es lo opuesto a una regla de incumplimiento de Rego. Para reutilizar una ValidatingAdmissionPolicy en varios ValidatingAdmissionPolicyBindings que proporcionan valores diferentes, usa un recurso de parámetro en lugar de una variable. Para obtener más información sobre los recursos de parámetros, consulta Recursos de parámetros en la documentación de Kubernetes.

En la siguiente tabla, se muestra cómo se asignan los campos de restricción a los campos ValidatingAdmissionPolicy y ValidatingAdmissionPolicyBinding:

Asignación de campos de restricción de Policy Controller a campos de ValidatingAdmissionPolicy y ValidatingAdmissionPolicyBinding
Campo de restricción Campo ValidatingAdmissionPolicy o ValidatingAdmissionPolicyBinding
spec.enforcementAction El campo validationActions en ValidatingAdmissionPolicyBinding, que asigna las acciones deny, warn y dryrun a los valores ["Deny"], ["Warn"] y ["Audit"]
spec.parameters El campo variables en ValidatingAdmissionPolicy o un recurso de parámetro al que hace referencia ValidatingAdmissionPolicyBinding en el campo paramRef
spec.match.kinds El campo matchConstraints.resourceRules en la ValidatingAdmissionPolicy, que usa grupos de API y nombres de recursos, como el recurso pods, en lugar de tipos
spec.match.namespaces y spec.match.excludedNamespaces El campo matchResources.namespaceSelector en el ValidatingAdmissionPolicyBinding, con el operador In o NotIn en la etiqueta kubernetes.io/metadata.name
spec.match.labelSelector El campo matchResources.objectSelector en ValidatingAdmissionPolicyBinding
spec.match.namespaceSelector El campo matchResources.namespaceSelector en ValidatingAdmissionPolicyBinding
spec.match.scope El campo scope de cada regla de recurso

Para obtener más información sobre cómo escribir expresiones, consulta CEL en Kubernetes en la documentación de Kubernetes.

Prueba las políticas junto con Policy Controller

Para reemplazar una restricción sin una brecha en la aplicación, ejecuta la ValidatingAdmissionPolicy junto a la restricción antes de aplicar la ValidatingAdmissionPolicy:

  1. Aplica ValidatingAdmissionPolicy y ValidatingAdmissionPolicyBinding que tenga el parámetro de configuración validationActions: ["Warn", "Audit"]. Deja la restricción de Policy Controller en su lugar.
  2. Compara los resultados con la consulta del registro de auditoría en Reemplaza los informes de incumplimiento. Si la ValidatingAdmissionPolicy marca las solicitudes que Policy Controller permite, o lo contrario, corrige la ValidatingAdmissionPolicy. Para las ValidatingAdmissionPolicies que coinciden con los Pods, no confíes en las advertencias. Los controladores crean los Pods para los Deployments y otras cargas de trabajo, por lo que el controlador recibe la advertencia.
  3. Después de que los resultados coincidan, cambia ValidatingAdmissionPolicyBinding para usar el parámetro de configuración validationActions: ["Deny"].
  4. Borra la restricción de Policy Controller.

Planifica para las diferencias de comportamiento

Las ValidatingAdmissionPolicies se comportan de manera diferente al Policy Controller de las siguientes maneras, lo que puede bloquear solicitudes o dejar brechas en la aplicación de políticas:

  • Política de fallas: El webhook de Policy Controller falla, lo que significa que el servidor de la API admite una solicitud si Policy Controller no responde. Un ValidatingAdmissionPolicy que tiene el parámetro de configuración failurePolicy: Fail rechaza una solicitud si una expresión devuelve un error o excede el límite de costo de CEL. ValidatingAdmissionPolicy también rechaza una solicitud si no existe un recurso de parámetro al que se hace referencia y el valor del campo paramRef.parameterNotFoundAction en ValidatingAdmissionPolicyBinding es Deny. Si el valor es Allow, el servidor de la API omite un recurso de parámetro faltante, sin importar el parámetro de configuración failurePolicy. Prueba cada ValidatingAdmissionPolicy y elige valores para ambos campos.
  • Campos faltantes: Rego trata un campo faltante como si no hubiera un incumplimiento, pero CEL devuelve un error. Antes de leer un campo opcional, usa la macro has() para verificar si el campo existe.
  • Exenciones: Una ValidatingAdmissionPolicy no exime los espacios de nombres de forma predeterminada ni usa la etiqueta admission.gatekeeper.sh/ignore. En los clústeres de GKE Standard, se aplica un ValidatingAdmissionPolicyBinding a cada espacio de nombres del clúster, incluidos los espacios de nombres del sistema, como el espacio de nombres kube-system, a menos que los excluyas en el campo matchResources.namespaceSelector del ValidatingAdmissionPolicyBinding o en los campos matchConstraints.namespaceSelector o matchConditions de la ValidatingAdmissionPolicy. En los clústeres de Autopilot, GKE excluye los espacios de nombres administrados automáticamente y rechaza las ValidatingAdmissionPolicies que coinciden con los recursos nodes, persistentVolumes, certificatesigningrequests o tokenreviews. Para obtener más información, consulta Medidas de seguridad de Autopilot de GKE.
  • Subrecursos: Policy Controller verifica las actualizaciones de Pods que agregan contenedores efímeros. Para mantener esa cobertura, incluye el subrecurso pods/ephemeralcontainers en tus reglas de recursos, como se hace en el ejemplo.
  • No hay auditoría de los recursos existentes: Una ValidatingAdmissionPolicy evalúa solo las solicitudes entrantes del servidor de la API. No informa los recursos existentes que incumplen una ValidatingAdmissionPolicy.
  • Un mensaje para cada solicitud: Una ValidatingAdmissionPolicy informa la primera validación que falla, no cada incumplimiento.

Usa la admisión de seguridad de Pods para los paquetes de seguridad de Pods

Si usas los paquetes pss-baseline-v2022 o pss-restricted-v2022, reemplaza el paquete por la admisión de seguridad de Pods en lugar de traducir cada restricción. La admisión de seguridad de Pods usa el controlador de admisión PodSecurity integrado de Kubernetes para aplicar reglas predefinidas de los estándares de seguridad de Pods de Kubernetes según las etiquetas de espacio de nombres. El paquete pss-baseline-v2022 corresponde al nivel baseline, y el paquete pss-restricted-v2022 corresponde al nivel restricted.

La admisión de seguridad de Pods no abarca todos los controles del paquete psp-v2022, como las listas de entidades permitidas para rutas de host, usuarios, capacidades y sysctls. Usa ValidatingAdmissionPolicies para esos controles. La admisión de seguridad de Pods tampoco puede eximir imágenes específicas, como las restricciones de Policy Controller que usan el parámetro exemptImages. GKE no admite la configuración de exenciones de la admisión de seguridad de Pods. Si necesitas excepciones, usa ValidatingAdmissionPolicies para las políticas afectadas.

Para obtener más información sobre cómo configurar la admisión de seguridad de Pods, consulta Aplica políticas de seguridad predefinidas a nivel de Pods con PodSecurity.

Migra a OPA Gatekeeper autoadministrado

Elige Gatekeeper para las políticas que ValidatingAdmissionPolicies no puede expresar. Policy Controller se basa en Gatekeeper, por lo que tus ConstraintTemplates y restricciones usan las mismas APIs en Gatekeeper. Todas las plantillas de la biblioteca de plantillas de Policy Controller funcionan en Gatekeeper sin cambios en su lógica. Sin embargo, Gatekeeper usa un motor de Rego más nuevo y una validación más estricta que puede rechazar una ConstraintTemplate personalizada.

Cuando usas Gatekeeper autoadministrado, eres responsable de las tareas que Google Cloud realiza para Policy Controller, como instalar, actualizar, escalar y supervisar Gatekeeper en cada clúster. Atención al cliente no admite Gatekeeper de código abierto. Para obtener ayuda, usa la herramienta de seguimiento de errores de Gatekeeper en GitHub.

Gatekeeper no incluye la biblioteca de plantillas de Policy Controller ni los paquetes de políticas. Tus archivos de copia de seguridad contienen las ConstraintTemplates y las restricciones de tus clústeres. Para las plantillas que se originaron en la biblioteca de código abierto de Gatekeeper, puedes usar las plantillas de la biblioteca de políticas de Gatekeeper. Los nombres de las plantillas siguen siendo los mismos, pero los parámetros y los mensajes pueden variar entre las versiones.

Para mover las políticas a Gatekeeper, sigue estos pasos:

  1. Opcional: Si no puedes aceptar una brecha en la aplicación de políticas mientras reemplazas Policy Controller, primero migra tus políticas más importantes a ValidatingAdmissionPolicies. Asegúrate de que esos ValidatingAdmissionPolicyBindings excluyan el espacio de nombres gatekeeper-system para que no bloqueen los trabajos de instalación de Gatekeeper. Después de quitar Policy Controller, tu clúster dejará de aplicar las políticas de Gatekeeper hasta que apliques las restricciones correspondientes de Gatekeeper. Los ValidatingAdmissionPolicies se siguen aplicando porque no dependen de Policy Controller ni de Gatekeeper.

  2. Si usas ConstraintTemplates personalizadas, prueba cada manifiesto de plantilla personalizada con la herramienta de línea de comandos de gator de la versión de Gatekeeper que planeas instalar:

    gator test --filename=TEMPLATE_FILE

    Reemplaza TEMPLATE_FILE por la ruta de acceso al archivo de manifiesto de ConstraintTemplate. Antes de quitar Policy Controller, corrige cualquier ConstraintTemplate personalizada que Gatekeeper rechace.

  3. Si implementas restricciones desde un repositorio de Git con una herramienta de GitOps, prepara las ConstraintTemplates que usan tus restricciones y agrégalas al repositorio cuando instales Gatekeeper. De lo contrario, tus restricciones no se aplicarán después de quitar Policy Controller porque sus ConstraintTemplates ya no existen.

  4. Quita Policy Controller siguiendo los pasos que se indican en Quita Policy Controller. No instales Gatekeeper en un clúster que aún ejecute Policy Controller. Ambos usan el espacio de nombres gatekeeper-system, las mismas CustomResourceDefinitions y los mismos nombres de webhook.

  5. Instala Gatekeeper con Helm y la configuración que elijas de la tabla de la siguiente sección, Configuración de Gatekeeper que difiere de Policy Controller. Para obtener más información sobre cómo instalar Gatekeeper, consulta Instalación en la documentación de Gatekeeper.

    En los clústeres de Autopilot, la instalación predeterminada del gráfico de Helm falla porque GKE rechaza las reglas de comodín en los webhooks de mutación. Establece el valor de Helm disableMutation: true o establece el valor de Helm mutatingWebhookCustomRules para enumerar solo los recursos específicos a los que se orientan tus mutadores. No incluyas los recursos nodes, persistentvolumes, certificatesigningrequests ni tokenreviews.

  6. En tus archivos de copia de seguridad, quita los siguientes campos, etiquetas y anotaciones de cada recurso que planees volver a aplicar:

    • El campo status
    • Los campos resourceVersion, uid, creationTimestamp, generation, managedFields y ownerReferences de la sección metadata.
    • La anotación kubectl.kubernetes.io/last-applied-configuration
    • Es la etiqueta app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com. Si Policy Controller se vuelve a habilitar en el clúster, por ejemplo, con una configuración predeterminada a nivel de la flota, administra los recursos que tienen esta etiqueta y puede modificarlos o borrarlos.
    • Etiquetas y anotaciones cuyas claves tienen el prefijo policycontroller..

  7. Aplica las ConstraintTemplates que usan tus restricciones y, luego, verifica que Gatekeeper haya creado una CustomResourceDefinition para cada plantilla:

    kubectl get constrainttemplates \
    -o custom-columns='NAME:.metadata.name,CREATED:.status.created'

    Cuando cada plantilla muestre un valor true en la columna CREATED, aplica tus restricciones.

Parámetros de configuración de Gatekeeper que difieren de Policy Controller

Antes de instalar Gatekeeper, revisa la configuración en la siguiente tabla, en la que los valores predeterminados del gráfico de Helm de Gatekeeper difieren de los de Policy Controller:

Comparación de los valores predeterminados de Policy Controller y los valores predeterminados del gráfico de Helm de Gatekeeper
Configuración Configuración predeterminada de Policy Controller Configuración predeterminada del gráfico de Helm de Gatekeeper Recomendación
Mutación Desactivado, a menos que lo hayas activado Activado Si no usas la mutación, establece el valor de Helm disableMutation: true. En los clústeres de Autopilot, debes establecer el valor de Helm disableMutation: true o configurar el valor de Helm mutatingWebhookCustomRules sin comodines ni recursos restringidos. Si no especificas uno de estos valores, GKE rechazará la instalación.
Exime espacios de nombres El espacio de nombres gatekeeper-system y los espacios de nombres de tu lista exemptableNamespaces Es el espacio de nombres en el que se instala Gatekeeper. Agrega tus espacios de nombres exentos al valor de Helm controllerManager.exemptNamespaces. Gatekeeper rechaza los cambios en los espacios de nombres que tienen la etiqueta admission.gatekeeper.sh/ignore, a menos que esos espacios de nombres estén exentos.
Datos de referencia Se sincronizan automáticamente para los paquetes de referencia. No sincronizada Crea un Config o SyncSet de Gatekeeper que enumere los tipos que leen tus plantillas de referencia. Hasta que esos tipos se sincronicen con el objeto data.inventory, las verificaciones de conflictos permiten las solicitudes infractoras, y las verificaciones de existencia, como la ConstraintTemplate K8sRequireNamespaceNetworkPolicies, rechazan todas las solicitudes coincidentes, incluso cuando existe el recurso requerido.
Generación de ValidatingAdmissionPolicy No disponible Activado para las plantillas que contienen código CEL Las plantillas de Policy Controller solo contienen Rego, por lo que Gatekeeper genera ValidatingAdmissionPolicies solo si agregas CEL a tus ConstraintTemplates. Para mantener la aplicación de políticas en el webhook, configura los valores de Helm defaultCreateVAPForTemplates: false y defaultCreateVAPBindingForConstraints: false. Para obtener más información, consulta Integración en la política de admisión de validación de Kubernetes en la documentación de Gatekeeper.
Réplicas y recursos Una réplica para cada componente, con un límite de memoria de 1,024 MiB Tres réplicas de webhook con diferentes límites de recursos Configura el recuento de réplicas y los límites de recursos según tu uso actual.
Imágenes Se extrae de un registro administrado por Google Extraídas de Docker Hub (las imágenes openpolicyagent/gatekeeper, openpolicyagent/gatekeeper-crds y curlimages/curl) Para los clústeres privados o los clústeres que aplican la Autorización Binaria, duplica las tres imágenes en Artifact Registry y anula sus valores de imagen en el gráfico. Si no duplicas la imagen de curlimages/curl, inhabilita el trabajo de sondeo de webhook.

De forma predeterminada, Gatekeeper solo expone las métricas de Prometheus, y sus nombres de métricas son diferentes de los nombres que Policy Controller envía a Cloud Monitoring. Actualiza los paneles y las alertas que usen métricas de Policy Controller.

Migra las políticas de mutación

Si habilitaste la mutación en Policy Controller, enumera tus mutadores:

kubectl get assign,assignmetadata,assignimage,modifyset

Para cada mutador, elige una de las siguientes opciones:

  • MutatingAdmissionPolicy: Puedes usar una MutatingAdmissionPolicy en la versión 1.36 y posteriores de GKE. Al igual que una ValidatingAdmissionPolicy, una MutatingAdmissionPolicy usa expresiones de CEL y se ejecuta en el servidor de la API sin un webhook. Kubernetes ejecuta todas las MutatingAdmissionPolicies antes de las ValidatingAdmissionPolicies, por lo que debes probarlas juntas para asegurarte de que una mutación no haga que una ValidatingAdmissionPolicy rechace un manifiesto válido. En los clústeres de Autopilot, GKE excluye los espacios de nombres administrados de MutatingAdmissionPolicies. Para obtener más información sobre las políticas de mutación, consulta Política de admisión de mutación en la documentación de Kubernetes.
  • Gatekeeper autoadministrado: En los clústeres de Standard, tus mutadores funcionan sin cambios porque Gatekeeper activa la mutación de forma predeterminada. En los clústeres de Autopilot, debes establecer el valor de Helm mutatingWebhookCustomRules en el gráfico de Gatekeeper para enumerar los recursos específicos a los que se dirigen tus mutadores en lugar de las reglas de comodín. Para obtener más información, consulta Medidas de seguridad de Autopilot de GKE. Después de instalar Gatekeeper, quita los metadatos de Policy Controller del archivo de copia de seguridad del mutador y vuelve a aplicar los mutadores, como lo haces con las restricciones.

Actualiza las verificaciones de políticas en las canalizaciones de compilación

Es posible que tu canalización de compilación verifique los manifiestos con las restricciones de Policy Controller antes de la implementación. Por ejemplo, la canalización podría usar la función gatekeeper en kpt o la herramienta de línea de comandos de gator. Para obtener más información, consulta Valida apps en función de las políticas de la empresa en una canalización de CI.

Si tu canalización verifica los manifiestos, actualízala para el reemplazo:

  • Si usas Gatekeeper, puedes conservar tu canalización. Actualiza las rutas de acceso de archivos o directorios en tu comando gator o kpt para hacer referencia al repositorio o directorio que contiene los manifiestos de ConstraintTemplate y de restricción de Gatekeeper limpios.

  • Si usas ValidatingAdmissionPolicies, esas herramientas no evalúan tus políticas. En su lugar, ejecuta una ejecución de prueba del servidor en un clúster de prueba que tenga tus ValidatingAdmissionPolicies y ValidatingAdmissionPolicyBindings que usen la acción Deny:

    kubectl apply --dry-run=server -f MANIFEST_DIRECTORY

    Reemplaza MANIFEST_DIRECTORY por el directorio que contiene tus manifiestos. El comando falla si una ValidatingAdmissionPolicy rechaza un manifiesto.

Reemplazar los informes de incumplimientos

Una ValidatingAdmissionPolicy no incluye un panel y no audita los recursos que ya existen en tu clúster. En su lugar, usa los siguientes métodos:

  • Advertencias: Si un ValidatingAdmissionPolicyBinding usa la acción Warn, el servidor de la API devuelve una advertencia al cliente que envió la solicitud, como la herramienta de línea de comandos kubectl. En el caso de los Pods que crea un controlador, como los Pods de un Deployment, el controlador recibe la advertencia.

  • Registros de auditoría: Si un ValidatingAdmissionPolicyBinding usa la acción Audit, el servidor de la API anota la entrada de registro de auditoría para cada validación con errores. GKE escribe solicitudes de creación, actualización y eliminación en los registros de auditoría de actividad del administrador en Cloud Logging. Para encontrar las validaciones con errores, ejecuta la siguiente consulta en el Explorador de registros:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
labels."validation.policy.admission.k8s.io/validation_failure":*

Si usas restricciones que tienen la dryrun medida por incumplimiento como un informe de cumplimiento de los recursos existentes, ValidatingAdmissionPolicies no puede reemplazar ese informe. Mantén esas políticas en el Gatekeeper autoadministrado, cuyo controlador de auditoría verifica los recursos existentes según un programa.

Quita Policy Controller

Antes de quitar Policy Controller de un clúster, completa las siguientes tareas:

  • Confirma que se apliquen las políticas que migraste a ValidatingAdmissionPolicies o a la admisión de seguridad de Pods, y que tengas una copia de seguridad de tus ConstraintTemplates, restricciones y mutadores. Si quitas Policy Controller, se borrarán sus CustomResourceDefinitions, lo que borrará todas las ConstraintTemplates, restricciones y mutadores del clúster, incluidos los que creaste.
  • Si implementas restricciones desde un repositorio de Git con una herramienta de GitOps, como el Sincronizador de configuración o Argo CD, quita las restricciones reemplazadas del repositorio. Confirma que se quitaron las restricciones de tus clústeres.
  • Opcional: Para confirmar que nada depende del webhook de Policy Controller, suspende Policy Controller primero. La suspensión solo quita las configuraciones de webhook, y puedes restablecerlas.

Para quitar Policy Controller, sigue estos pasos:

  1. Desinstala Policy Controller de tus clústeres:

    gcloud container fleet policycontroller disable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID

    Reemplaza lo siguiente:

    • MEMBERSHIP_NAME: Es el nombre de la membresía del clúster registrado del que deseas desinstalar Policy Controller. Para desinstalar Policy Controller de varios clústeres, especifica una lista de nombres de membresía separados por comas o reemplaza la marca --memberships=MEMBERSHIP_NAME por la marca --all-memberships.
    • PROJECT_ID: el ID del proyecto host de tu flota.

  2. Confirma que Policy Controller haya terminado de desinstalarse de tus clústeres:

    gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

    Espera hasta que el valor del campo policycontroller.state de nivel superior de cada membresía sea NOT_INSTALLED, no DECOMMISSIONING. Las entradas individuales de componentStates alcanzan el estado NOT_INSTALLED antes de que finalice la limpieza de CustomResourceDefinition.

    Si planeas instalar Gatekeeper autoadministrado, confirma que el espacio de nombres gatekeeper-system ya no exista:

    kubectl get namespace gatekeeper-system

    Espera hasta que el resultado informe que no se encuentra el espacio de nombres gatekeeper-system.

  3. Opcional: Para evitar que los clústeres que registres más adelante obtengan Policy Controller, quita la configuración predeterminada a nivel de la flota:

    gcloud container fleet policycontroller enable \
    --no-fleet-default-member-config \
    --project=PROJECT_ID

    Este comando solo quita la configuración predeterminada. No instala Policy Controller en ningún clúster.

Quita Policy Controller de los clústeres fuera de una flota

El comando gcloud container fleet policycontroller disable quita Policy Controller solo de los clústeres que administra la flota. Un clúster puede ejecutar Policy Controller sin administración de flotas en los siguientes casos:

  • Instalaste Policy Controller con el operador de ConfigManagement.
  • Cancelaste el registro del clúster de su flota o ejecutaste el comando gcloud container fleet policycontroller detach antes de que Policy Controller terminara de desinstalarse.

Para quitar Policy Controller de estos clústeres, colócalos en la administración de flotas y, luego, desinstala Policy Controller:

  1. Crea una copia de seguridad de tus ConstraintTemplates, restricciones, configuración de sincronización y mutadores, como se describe en Crea un inventario y clasifica tus políticas. Cuando limpies los metadatos de las copias de seguridad tomadas de una instalación del operador de ConfigManagement, también quita las etiquetas configmanagement.gke.io/* y k8s-app: kubernetes-config-management, además del campo ownerReferences y los metadatos policycontroller.*.

  2. Si instalaste Policy Controller con el operador de ConfigManagement, quita el campo policyController del recurso personalizado de ConfigManagement en el clúster. Espera hasta que se complete la conciliación. La conciliación puede tardar alrededor de dos minutos. Luego, verifica si el espacio de nombres gatekeeper-system aún existe:

    kubectl get namespace gatekeeper-system

    En la versión 1.17 y anteriores del operador de ConfigManagement, quitar el campo policyController desinstala Policy Controller automáticamente. Si no se encuentra el espacio de nombres gatekeeper-system, omite los pasos restantes de esta sección. En la versión 1.18 y posteriores del operador de ConfigManagement, el espacio de nombres gatekeeper-system permanece en el clúster, por lo que debes continuar con el siguiente paso.

  3. Si el clúster no está registrado en una flota, regístralo. Para obtener más información, consulta Registra un clúster en Google Cloud en tu flota.

  4. Verifica si la mutación está habilitada en el clúster:

    kubectl get mutatingwebhookconfiguration \
    gatekeeper-mutating-webhook-configuration

  5. Habilita Policy Controller en la membresía del clúster para que la flota asuma la administración de la instalación existente. Si el comando anterior devolvió el recurso gatekeeper-mutating-webhook-configuration, incluye la marca --mutation para que la flota adopte y, luego, quite los recursos de mutación con alcance de clúster:

    gcloud container fleet policycontroller enable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID

    Reemplaza lo siguiente:

    • MEMBERSHIP_NAME: Es el nombre de la membresía de tu clúster registrado.
    • PROJECT_ID: el ID del proyecto host de tu flota.

  6. Espera hasta que el valor del campo policycontroller.state de la membresía sea ACTIVE:

    gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

  7. Desinstala Policy Controller siguiendo los pasos que se indican en Quita Policy Controller. Si no instalas Gatekeeper autoadministrado, borra cualquier CustomResourceDefinition de restricción restante después de que se quite el espacio de nombres gatekeeper-system:

    kubectl get crd -o name \
    | grep '\.constraints\.gatekeeper\.sh$' \
    | xargs -r kubectl delete

  8. Opcional: Si registraste el clúster solo para completar este procedimiento, cancela el registro después de que el comando describe muestre el estado NOT_INSTALLED para la membresía. Para los clústeres que registraste con la marca --enable-fleet, ejecuta el comando gcloud container clusters update con la marca --clear-fleet-project en lugar del comando gcloud container fleet memberships unregister. Para obtener más información, consulta Anula el registro de un clúster.

¿Qué sigue?