Comprender Azure Policy para clústeres de Kubernetes

Azure Policy extiende Gatekeeper v3, una admission controller webhook para Open Policy Agent (OPA), para aplicar medidas de seguridad y cumplimiento a escala en los componentes del clúster de forma centralizada y coherente. Los componentes del clúster incluyen pods, contenedores y espacios de nombres.

Azure Policy permite administrar e informar sobre el estado de cumplimiento de los componentes del clúster de Kubernetes desde un solo lugar. Mediante el uso del complemento o la extensión de Azure Policy, el gobierno de los componentes del clúster se mejora con características de Azure Policy, como la capacidad de usar selectors y overrides para la implementación y reversión de directivas seguras.

Azure Policy para Kubernetes admite los siguientes entornos de clúster:

• Azure Kubernetes Service (AKS), a través del Add-on de Azure Policy para AKS
• Azure Arc habilitado para Kubernetes a través de Extensión de Azure Policy de Arc

Información general

Al instalar el complemento o la extensión de Azure Policy en los clústeres de Kubernetes, Azure Policy establece las funciones siguientes:

• Verifica con el servicio de Azure Policy para las asignaciones de directivas del clúster.
• Implementa definiciones de directiva en el clúster como plantilla de restricción y recursos personalizados de restricción o como un recurso de plantilla de mutación (según el contenido de la definición de directiva).
• Notifica los detalles de auditoría y cumplimiento al servicio Azure Policy.

Para habilitar y usar Azure Policy con el clúster de Kubernetes, realice las siguientes acciones:

1. Configure el clúster de Kubernetes e instale el complemento Azure Kubernetes Service (AKS) o la extensión de Azure Policy para clústeres de Kubernetes habilitados para Arc (según el tipo de clúster).

   Nota:

   Para conocer los problemas comunes de instalación, consulte Troubleshoot - Complemento de Azure Policy.

2. Crear o usar una definición de Azure Policy de ejemplo para Kubernetes

3. Asignación de una definición a un clúster de Kubernetes

4. Espere la validación

5. Registro y solución de problemas

6. Revisión de las limitaciones y las recomendaciones de nuestra sección de preguntas más frecuentes

Instalar el complemento de Azure Policy para AKS

El complemento Azure Policy para AKS forma parte de la versión 1.27 de Kubernetes con compatibilidad a largo plazo (LTS).

Requisitos previos

1. Registre los proveedores de recursos y las características en vista previa.

   • Azure portal:

     Registre los proveedores de recursos Microsoft.PolicyInsights. Para conocer los pasos, consulte Proveedores de recursos y sus tipos.

   • CLI de Azure:

     # Log in first with az login if you're not using Cloud Shell
     
     # Provider register: Register the Azure Policy provider
     az provider register --namespace Microsoft.PolicyInsights
     

2. Necesita que la versión 2.12.0 o posterior de CLI de Azure esté instalada y configurada. Para encontrar la versión, ejecute el comando az --version. Si necesita instalar o actualizar, consulte Cómo instalar el CLI de Azure.

3. El clúster de AKS debe ser una versión de Kubernetes compatible en Azure Kubernetes Service (AKS). Use el siguiente script para validar la versión del clúster de AKS:

   # Log in first with az login if you're not using Cloud Shell
   
   # Look for the value in kubernetesVersion
   az aks list
   

4. Abra puertos para la extensión Azure Policy. La extensión Azure Policy usa estos dominios y puertos para capturar las definiciones de directiva y las asignaciones y notificar el cumplimiento del clúster en Azure Policy.

   Dominio	Puerto
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

Una vez completados los requisitos previos, instale el complemento Azure Policy en el clúster de AKS que desea administrar.

• portal de Azure

  1. Inicie el servicio AKS en el portal de Azure seleccionando Todos los servicios y, a continuación, busque y seleccione Servicios dekubernetes.

  2. Seleccione uno de sus clústeres de AKS.

  3. Seleccione Directivas en el lado izquierdo de la página de servicio de Kubernetes.

  4. En la página principal, seleccione el botón Enable add-on (Habilitar complemento).

• CLI de Azure

  # Log in first with az login if you're not using Cloud Shell
  
  az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
  

Para comprobar que la instalación del complemento se ha realizado correctamente y que los pods azure-policy y gatekeeper están en ejecución, ejecute el comando siguiente:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Por último, compruebe que el complemento más reciente está instalado ejecutando este comando de CLI de Azure, reemplazando <rg> por el nombre del grupo de recursos y <cluster-name> por el nombre del clúster de AKS: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. El resultado debe ser similar al siguiente para clústeres que utilizan principales de servicio:

{
  "config": null,
  "enabled": true,
  "identity": null
}

Y la salida siguiente para los clústeres que usan identidad administrada:

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

Instalar la extensión Azure Policy para Kubernetes habilitado con Azure Arc

Azure Policy para Kubernetes permite administrar e informar sobre el estado de cumplimiento de los clústeres de Kubernetes desde un solo lugar. Con la extensión de Azure Policy para clústeres de Kubernetes habilitados para Arc, puede controlar los componentes del clúster de Kubernetes habilitados para Arc, como pods y contenedores.

En este artículo se describe cómo crear, mostrar el estado de la extensión y eliminar la extensión de Azure Policy para Kubernetes.

Para obtener información general sobre la plataforma de extensiones, consúltese extensiones de clúster de Azure Arc.

Requisitos previos

Si ya ha implementado Azure Policy para Kubernetes en un clúster de Azure Arc mediante Helm directamente sin extensiones, siga las instrucciones para delete el gráfico de Helm. Una vez que se haya completado la eliminación, puede continuar.

1. Asegúrese de que el clúster de Kubernetes es una distribución compatible.

   Nota:

   Azure Policy para la extensión Arc se admite en las siguientes distribuciones de Kubernetes.

2. Asegúrese de que cumple todos los requisitos previos comunes de las extensiones de Kubernetes enumeradas aquí, incluido el hecho de conectar su clúster a Azure Arc.

   Nota:

   La extensión de Azure Policy es compatible para los clústeres de Kubernetes habilitados para Arc en estas regiones.

3. Abra puertos para la extensión Azure Policy. La extensión Azure Policy usa estos dominios y puertos para capturar las definiciones de directiva y las asignaciones y notificar el cumplimiento del clúster en Azure Policy.

   Dominio	Puerto
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

4. Antes de instalar la extensión Azure Policy o habilitar cualquiera de las características de servicio, la suscripción debe habilitar los proveedores de recursos Microsoft.PolicyInsights.

   Nota:

   Para habilitar el proveedor de recursos, siga los pasos descritos en Resource providers and types o ejecute el comando CLI de Azure o Azure PowerShell.

   • CLI de Azure

     # Log in first with az login if you're not using Cloud Shell
     # Provider register: Register the Azure Policy provider
     az provider register --namespace 'Microsoft.PolicyInsights'
     

   • Azure PowerShell

     # Log in first with Connect-AzAccount if you're not using Cloud Shell
     
     # Provider register: Register the Azure Policy provider
     Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
     

Creación de una extensión de Azure Policy

Para crear una instancia de la extensión, para el clúster habilitado para Arc, ejecute el siguiente comando, sustituyendo <> por sus valores:

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

Ejemplo:

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

Salida de ejemplo:

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

Mostrar extensión de Azure Policy

Para comprobar que la creación de la instancia de la extensión se ha realizado correctamente e inspeccionar los metadatos de la extensión, ejecute el siguiente comando sustituyendo <> por sus valores:

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Ejemplo:

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

Para comprobar que la instalación de la extensión se ha realizado correctamente y que los pods azure-policy y gatekeeper están en ejecución, ejecute el comando siguiente:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Eliminar extensión de Azure Policy

Para eliminar la instancia de la extensión, ejecute el siguiente comando, sustituyendo <> por sus valores:

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Crear una definición de directiva

La estructura de lenguaje Azure Policy para administrar Kubernetes sigue la de las definiciones de directiva existentes. Hay archivos de definición de ejemplo disponibles para asignar desde la biblioteca de directivas integrada de Azure Policy que se pueden usar para gestionar los componentes del clúster.

Azure Policy para Kubernetes también admite la creación de definiciones personalizadas a nivel de componente para clústeres de Azure Kubernetes Service y clústeres de Kubernetes habilitados para Azure Arc. Las plantillas de restricción y los ejemplos de plantillas de mutación están disponibles en la biblioteca de la comunidad de Gatekeeper. La Extensión de Azure Policy para Visual Studio Code se puede usar para ayudar a traducir las plantillas de restricción o de mutación existentes en una definición de directiva personalizada de Azure Policy.

Con un modo de proveedor de recursos Resource de Microsoft.Kubernetes.Data, los efectos auditar, negar, deshabilitado y mutar se usan para administrar los clústeres de Kubernetes.

audit y deny deben proporcionar propiedades details específicas para trabajar con OPA Constraint Framework y Gatekeeper v3.

Como parte de las propiedades details.templateInfo o details.constraintInfo en la definición de directiva, Azure Policy pasa el valor URI o Base64Encoded de estos CustomResourceDefinitions(CRD) al complemento. Rego es el lenguaje que OPA y Gatekeeper admiten para validar una solicitud al clúster de Kubernetes. Al admitir un estándar existente para la administración de Kubernetes, Azure Policy permite reutilizar las reglas existentes y emparejarlas con Azure Policy para una experiencia unificada de informes de cumplimiento en la nube. Para obtener más información, consulte ¿Qué es Rego?

Asignación de una definición de directiva

Para asignar una definición de directiva a su clúster de Kubernetes, debe tener asignadas las operaciones adecuadas de asignación de directivas dentro del Control de acceso basado en roles de Azure (Azure RBAC). Los roles integrados Azure Resource Policy Contributor y Owner tienen estas operaciones. Para obtener más información, consulte Permisos de Azure RBAC en Azure Policy.

Busque las definiciones de directivas integradas para administrar el clúster mediante el portal de Azure con los pasos siguientes. Si usa una definición de directiva personalizada, busque por nombre o por la categoría con la que la creó.

1. Inicie el servicio Azure Policy en el portal de Azure. Seleccione All services (Todos los servicios) en el panel izquierdo y busque y seleccione la opción Policy (Directiva).

2. En el panel izquierdo de la página de Azure Policy, seleccione Definitions.

3. En el cuadro de lista desplegable Categoría, use Seleccionar todo para borrar el filtro y seleccione Kubernetes.

4. Seleccione la definición de directiva y pulse el botón Assign (Asignar).

5. Establezca el Ámbito en el grupo de administración, la suscripción o el grupo de recursos del clúster de Kubernetes al que se aplicará la asignación de directiva.

   Nota:

   Al asignar el Azure Policy para la definición de Kubernetes, el Scope debe incluir el recurso de clúster.

6. Asigne un Nombre y una Descripción a la asignación de directiva que pueda usar para identificarla con facilidad.

7. Establezca Cumplimiento de directivas en uno de los valores siguientes:

   • Habilitado: aplicar la directiva en el clúster. Se deniegan las solicitudes de admisión de Kubernetes que contienen infracciones.

   • Deshabilitado: no aplicar la directiva en el clúster. No se deniegan las solicitudes de admisión de Kubernetes con infracciones. Los resultados de la evaluación de cumplimiento siguen estando disponibles. Al implementar nuevas definiciones de directiva para ejecutar clústeres, la opción Deshabilitado resulta útil para probar la definición de directiva, ya que las solicitudes de admisión con infracciones no se deniegan.

8. Seleccione Siguiente.

9. Establecer Valores de parámetros

   • Para excluir los espacios de nombres de Kubernetes de la evaluación de políticas, especifique la lista de espacios de nombres en el parámetro Exclusiones de espacios de nombres. Se recomienda excluir: kube-system, gatekeeper-system y azure-arc.

10. Seleccione Revisar + crear.

Como alternativa, use el inicio rápido Asignación de una directiva: Portal para buscar y asignar una directiva de Kubernetes. Busque una definición de directiva de Kubernetes en lugar del ejemplo audit vms.

Evaluación de política

El complemento consulta con el servicio de Azure Policy para ver cambios en las asignaciones de directivas cada 15 minutos. Durante este ciclo de actualización, el complemento comprueba si hay cambios. Estos cambios desencadenan la creación, actualización o eliminación de restricciones y plantillas de restricciones.

En un clúster de Kubernetes, si un espacio de nombres tiene la etiqueta adecuada para el clúster, no se deniegan las solicitudes de admisión con infracciones. Los resultados de la evaluación de cumplimiento siguen estando disponibles.

• clúster de Kubernetes habilitado para Azure Arc: admission.policy.azure.com/ignore

Cada 15 minutos, el complemento solicita un examen completo del clúster. Después de recopilar detalles del examen completo y las evaluaciones en tiempo real por Gatekeeper de los cambios intentados en el clúster, el complemento notifica los resultados a Azure Policy para su inclusión en detalles de cumplimiento como cualquier asignación de Azure Policy. Solo los resultados de las asignaciones de directivas activas se devuelven durante el ciclo de auditoría. Los resultados de la auditoría también pueden verse como infracciones enumeradas en el campo de estado de la restricción errónea. Para obtener más información sobre recursos no compatibles, consulte Detalles de los componentes de los modos de proveedor de recursos.

Otras consideraciones:

• Si la suscripción de clúster se registra con Microsoft Defender for Cloud, Microsoft Defender for Cloud las directivas de Kubernetes se aplican automáticamente en el clúster.

• Cuando se aplica una directiva de denegación en un clúster que ya tiene recursos de Kubernetes, los recursos ya existentes que no son compatibles con la nueva directiva siguen en ejecución. Cuando un recurso que no es compatible vuelve a programarse en un nodo diferente, Gatekeeper bloquea la creación de recursos.

• Si un clúster tiene una directiva de denegación que valida los recursos, no se muestra ningún mensaje de rechazo al usuario cuando crea una implementación. Por ejemplo, considere una implementación de Kubernetes que contiene replicasets y pods. Cuando un usuario ejecute kubectl describe deployment $MY_DEPLOYMENT, no se devolverá un mensaje de rechazo durante los eventos. Sin embargo, kubectl describe replicasets.apps $MY_DEPLOYMENT sí devolverá los eventos relacionados con el rechazo.

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

Conflictos de plantilla de restricciones

Si las plantillas de restricciones tienen el mismo nombre de los metadatos de recursos, pero la definición de directiva hace referencia al origen en ubicaciones diferentes, se considera que las definiciones de directiva están en conflicto. Ejemplo: dos definiciones de directiva hacen referencia al mismo archivo de template.yaml almacenados en ubicaciones de origen diferentes, como el almacén de plantillas de Azure Policy (store.policy.core.windows.net) y GitHub.

Cuando se asignan las definiciones de directiva y sus plantillas de restricciones, pero aún no están instaladas en el clúster y están en conflicto, se notifican como un conflicto y no se instalan en el clúster hasta que este se resuelva. Del mismo modo, las definiciones de directiva existentes y sus plantillas de restricciones que ya están en el clúster que entren en conflicto con las definiciones de directiva recién asignadas seguirán funcionando con normalidad. Si se actualiza una asignación existente y se produce un error al sincronizar la plantilla de restricciones, el clúster también se marca como un conflicto. Para ver todos los mensajes de conflicto, consulte Motivos de cumplimiento del modo del proveedor de recursos de AKS

Registro

Como controlador o contenedor de Kubernetes, los pods azure-policy y gatekeeper mantienen registros en el clúster de Kubernetes. En general, los registros de azure-policy se pueden usar para solucionar problemas con la ingesta de directivas en el clúster y los informes de cumplimiento. Los registros de pod de gatekeeper-controller-manager se pueden usar para solucionar problemas de denegación en tiempo de ejecución. Los registros de pod de gatekeeper-audit se pueden usar para solucionar problemas de auditorías de los recursos existentes. Los registros se pueden exponer en la página Insights (Detalles) del clúster de Kubernetes. Para más información, consulte Monitor el rendimiento del clúster de Kubernetes con Azure Monitor para contenedores.

Para ver los registros del complemento, use kubectl:

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

Si está intentando solucionar problemas de un código ComplianceReasonCode determinado que aparece en los resultados de cumplimiento, puede buscar los registros de pod de azure-policy para ese código para ver el error complementario completo.

Para obtener más información, vea Depuración de Gatekeeper en la documentación de Gatekeeper.

Visualización de artefactos de Gatekeeper

Después de que el complemento descargue las asignaciones de directiva e instale las plantillas de restricción y restricciones en el clúster, anota ambas con información de Azure Policy como el identificador de asignación de directiva y el identificador de definición de directiva. Para configurar el cliente para ver los artefactos relacionados con el complemento, siga estos pasos:

1. Configure kubeconfig para el clúster.

   Para un clúster de Azure Kubernetes Service, use el siguiente CLI de Azure:

   # Set context to the subscription
   az account set --subscription <YOUR-SUBSCRIPTION>
   
   # Save credentials for kubeconfig into .kube in your home folder
   az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>
   

2. Pruebe la conexión del clúster.

   Ejecute el comando kubectl cluster-info. Una ejecución correcta hace que cada servicio responda con una dirección URL de dónde se ejecuta.

Ver las plantillas de restricciones del complemento

Para ver las plantillas de restricción descargadas por el complemento, ejecute kubectl get constrainttemplates. Las plantillas de restricción que comienzan por k8sazure son las instaladas por el complemento.

Visualización de las plantillas de mutación del complemento

Para ver las plantillas de mutación descargadas por el complemento, ejecute kubectl get assign, kubectl get assignmetadata y kubectl get modifyset.

Obtener las asignaciones de Azure Policy

Para identificar la asignación entre una plantilla de restricción descargada en el clúster y la definición de directiva, use kubectl get constrainttemplates <TEMPLATE> -o yaml. El resultado es similar a la siguiente salida:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> es el identificador de suscripción y <GUID> es el identificador de la definición de directiva mapeada. <URL-OF-YAML> es la ubicación de origen de la plantilla de restricción que descargó el complemento para instalar en el clúster.

Visualización de las restricciones relacionadas con una plantilla de restricción

Una vez que tenga los nombres de las plantillas de restricción descargadas del complemento, puede usar el nombre para ver las restricciones relacionadas. Use kubectl get <constraintTemplateName> para obtener la lista. Las restricciones instaladas por el complemento comienzan con azurepolicy-.

Visualización de los detalles de la restricción

La restricción tiene detalles sobre las infracciones y asignaciones a la definición y asignación de directiva. Para ver los detalles, use kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml. El resultado es similar a la siguiente salida:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

Solución de problemas del complemento

Para más información sobre cómo solucionar problemas del complemento para Kubernetes, consulte la sección Kubernetes del artículo de solución de problemas de Azure Policy.

Para problemas relacionados con la extensión de Azure Policy para Arc, vaya a:

• solución de problemas de Kubernetes habilitada para Azure Arc

Para problemas relacionados con Azure Policy, vaya a:

• Inspect registros de Azure Policy
• solución de problemas general de Azure Policy en Kubernetes

Azure Policy complemento para AKS Changelog

El complemento de Azure Policy para AKS tiene un número de versión que indica la versión de la imagen del complemento. A medida que la compatibilidad con características se introduce recientemente en el complemento, el número de versión aumenta.

Esta sección le ayuda a identificar qué versión del complemento está instalada en el clúster y también compartir una tabla histórica de la versión de complemento de Azure Policy instalada por clúster de AKS.

Identificación de la versión del complemento instalada en el clúster

El complemento de Azure Policy usa el esquema estándar Semantic Versioning para cada versión. Para identificar la versión del complemento de Azure Policy que se usa, puede ejecutar el siguiente comando: kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

Para identificar la versión de Gatekeeper que usa el complemento de Azure Policy, puede ejecutar el siguiente comando: kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

Por último, para identificar la versión del clúster de AKS que está utilizando, siga la guía de AKS vinculada.

Versiones de complemento disponibles por cada versión del clúster de AKS

1.16.1

Introducción a la generación de políticas de admisión validadas (VAP). Las políticas de admisión de validación son recursos de política nativos de Kubernetes que se evalúan en proceso, lo que permite una menor latencia y una evaluación con cierre en caso de fallo. Las directivas de Azure que contienen Common Expression Language (CEL) generarán automáticamente VAP. Para obtener más información, vea la documentación de Gatekeeper. Patch CVE-2026-25679, CVE-2026-27142, CVE-2026-27139 y CVE-2026-32280. Mejoras de seguridad.

• Fecha de publicación: mayo de 2026
• Kubernetes: 1.36+
• Gatekeeper: 3.22.1

Gatekeeper 3.22.1

Versión de Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.22.1 Cambios: https://github.com/open-policy-agent/gatekeeper/compare/v3.20.1...v3.22.1

1.15.5

Mejoras de seguridad.

• Fecha de publicación: febrero de 2026
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.15.4

Patch CVE-2025-61727. Mejoras de seguridad.

• Fecha de publicación: dic 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.15.3

Patch CVE-2025-47914, CVE-2025-58181, CVE-2025-58187 y CVE-2025-22872. Mejoras de seguridad.

• Fecha de publicación: dic 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.15.1

Mejoras de seguridad.

• Fecha de publicación: noviembre de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.14.2

Parche CVE-2025-4802. Mejoras de seguridad.

• Fecha de publicación: octubre de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

Gatekeeper 3.20.1

Versión de Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.1 Cambios: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.1

1.13.1

Patch CVE-2025-47907. Mejoras de seguridad.

• Fecha de publicación: agosto de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.0

1.13.0

Límite de datos de la UE ahora compatible con Azure Policy para Kubernetes en AKS. Para obtener más información sobre el límite de datos de la UE, visite Introducción a los límites de datos de la UE. Parche CVE-2025-22874. Mejoras de seguridad.

• Fecha de publicación: julio de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.0

Gatekeeper 3.20.0

Versión de Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.0 Cambios: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.0

1.12.3

Patch CVE-2025-22874 y GHSA-vrw8-fxc6-2r93. Mejoras de seguridad.

• Fecha de publicación: julio de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.19.1

1.12.2

Mejoras de seguridad.

• Fecha de publicación: junio de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.19.1

1.11.1

Parche CVE-2025-22872. Mejoras de seguridad.

• Fecha de publicación: mayo de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.19.1

Gatekeeper 3.19.1

Versión de Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.19.1 Cambios: https://github.com/open-policy-agent/gatekeeper/compare/v3.18.2...v3.19.1

1.10.1

Patch CVE-2025-30204 y CVE-2025-22870. Mejoras de seguridad.

• Fecha de publicación: abril de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.18.2

1.10.0

CEL está habilitado de forma predeterminada, puede seguir usando Rego. Se introduce un nuevo CRD configpodstatuses.status.gatekeeper.sh (Referencia: https://github.com/open-policy-agent/gatekeeper/issues/2918). Mejoras de seguridad.

• Fecha de publicación: febrero de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.18.2

Gatekeeper 3.18.2

Versión de Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.18.2 Cambios: https://github.com/open-policy-agent/gatekeeper/compare/v3.17.1...v3.18.2

1.9.1

Revisión CVE-2024-45337 y CVE-2024-45338. Mejoras de seguridad.

• Fecha de publicación: enero de 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.17.1

Gatekeeper 3.17.1

Versión de Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.17.1

1.8.0

Ahora se puede usar la directiva para evaluar las operaciones de CONNECT, por ejemplo, para denegar execs. Tenga en cuenta que no hay ningún cumplimiento de brownfield disponible para las operaciones de CONNECT no conformes, por lo que una directiva con efecto auditoría que tiene como destino CONNECTT no es una operación. Mejoras de seguridad.

• Fecha de publicación: noviembre de 2024
• Kubernetes: 1.27+
• Gatekeeper: 3.17.1

1.7.1

Presentación de CEL y VAP. Common Expression Language (CEL) es un lenguaje de expresiones nativas de Kubernetes que se puede usar para declarar reglas de validación de una directiva. La característica validar la directiva de admisión (VAP) proporciona evaluación de directivas en árbol, reduce la latencia de las solicitudes de admisión y mejora la confiabilidad y la disponibilidad. Las acciones de validación admitidas incluyen Deny, Warn y Audit. Se permite la creación de directivas personalizadas para CEL/VAP y los usuarios existentes no tendrán que convertir su Rego a CEL, ya que se admitirán y se usarán para aplicar directivas. Para usar CEL y VAP, los usuarios deben inscribirse en el flag de características AKS-AzurePolicyK8sNativeValidation en el espacio de nombres Microsoft.ContainerService. Para obtener más información, vea la documentación de Gatekeeper. Mejoras de seguridad.

• Fecha de publicación: septiembre de 2024
• Kubernetes: 1.27+ (la generación de VAP solo se admite en la versión 1.30 o posterior)
• Gatekeeper: 3.17.1

1.7.0

Introducción a la expansión, una característica de desplazamiento a la izquierda que le permite saber por adelantado si los recursos de carga de trabajo (Implementaciones, ReplicaSets, Trabajos, etc.) producirán pods admisibles. La expansión no debe cambiar el comportamiento de las directivas; en su lugar, simplemente desplaza la evaluación de las directivas de ámbito de pod de Gatekeeper para que se produzcan en el momento de admisión de la carga de trabajo en lugar del tiempo de admisión del pod. Pero para realizar esta evaluación, debe generar y evaluar un pod hipotético basado en la especificación de pod definida en la carga de trabajo, que puede tener metadatos incompletos. Por ejemplo, el pod hipotético no contendrá las referencias de propietario adecuadas. Debido a este pequeño riesgo de cambio de comportamiento de directiva, estamos introduciendo la expansión como deshabilitada de forma predeterminada. Para habilitar la expansión de una definición de directiva determinada, establezca .policyRule.then.details.source en All. Los elementos integrados se actualizarán pronto para habilitar la parametrización de este campo. Si prueba la definición de la directiva y descubre que el pod what-if que se va a generar con fines de evaluación está incompleto, también puede usar una mutación con Generated de origen para mutar los pods what-if. Para obtener más información sobre esta opción, vea la documentación de Gatekeeper. La expansión solo está disponible actualmente en clústeres de AKS, no en clústeres de Arc. Mejoras de seguridad.

• Fecha de publicación: julio de 2024
• Kubernetes: 1.27+
• Gatekeeper: 3.16.3

1.6.1

Mejoras de seguridad.

• Fecha de publicación: mayo de 2024
• Gatekeeper: 3.14.2

1.5.0

Mejoras de seguridad.

• Fecha de publicación: mayo de 2024
• Kubernetes: 1.27+
• Gatekeeper: 3.16.3

1.4.0

Habilita la mutación y los datos externos de forma predeterminada. En el peor de los casos, el webhook de mutación adicional y un aumento de la validación del límite de tiempo de espera del webhook puede agregar latencia a las llamadas. También presenta compatibilidad para ver la definición de directiva y establecer la versión de definición en los resultados de cumplimiento. Mejoras de seguridad.

• Fecha de publicación: mayo de 2024
• Kubernetes: 1.25+
• Gatekeeper: 3.14.0

1.3.0

Introduce un estado de error para las directivas que están en un estado de error, lo que permite distinguirlas de las directivas en estados no conformes. Agrega compatibilidad con las plantillas de restricción v1 y el uso del excludedNamespaces parámetro en las directivas de mutación. Agrega una comprobación de estado de error en las plantillas de restricción posteriores a la instalación. Mejoras de seguridad.

• Fecha de publicación: febrero de 2024
• Kubernetes: 1.25+
• Gatekeeper: 3.14.0

1.2.1

Mejoras de seguridad.

• Fecha de publicación: octubre de 2023
• Kubernetes: 1.25+
• Gatekeeper: 3.13.3

1.1.0

Mejoras de seguridad.

• Fecha de publicación: julio de 2023
• Kubernetes: 1.27+
• Gatekeeper: 3.11.1

1.0.1

Mejoras de seguridad.

• Fecha de publicación: junio de 2023
• Kubernetes: 1.24+
• Gatekeeper: 3.11.1

1.0.0

Azure Policy para Kubernetes ahora admite la modificación para remediar clústeres de AKS a gran escala.

Eliminar el complemento

Eliminación del complemento de AKS

Para quitar el complemento de Azure Policy del clúster de AKS, use el portal de Azure o CLI de Azure:

• portal de Azure

  1. Inicie el servicio AKS en el portal de Azure seleccionando Todos los servicios y, a continuación, busque y seleccione Servicios dekubernetes.

  2. Seleccione el clúster de AKS en el que desea deshabilitar el complemento de Azure Policy.

  3. Seleccione Directivas en el lado izquierdo de la página de servicio de Kubernetes.

  4. En la página principal, pulse Disable add-on (Deshabilitar complemento).

• CLI de Azure

  # Log in first with az login if you're not using Cloud Shell
  
  az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
  

Eliminar el complemento de Kubernetes habilitado con Azure Arc

Para quitar el complemento Azure Policy y Gatekeeper del clúster de Kubernetes habilitado para Azure Arc, ejecute el siguiente comando de Helm:

helm uninstall azure-policy-addon

Eliminación del complemento desde AKS Engine

Para quitar el complemento Azure Policy y Gatekeeper del clúster del motor de AKS, use el método que se alinea con el modo en que se instaló el complemento:

• Si se ha instalado definiendo la propiedad addons en la definición del clúster para AKS Engine:

  Vuelva a implementar la definición del clúster en AKS Engine después de cambiar la propiedad addons de azure-policy a false:

  "addons": [
    {
      "name": "azure-policy",
      "enabled": false
    }
  ]
  

  Para obtener más información, vea AKS Engine - Disable Azure Policy Add-on.

• Si se ha instalado con gráficos de Helm, ejecute el siguiente comando de Helm:

  helm uninstall azure-policy-addon
  

Limitaciones

• Para obtener definiciones generales de Azure Policy y límites de asignación, revise los límites documentados de Azure Policy
• El complemento de Azure Policy para Kubernetes solo se puede implementar en grupos de nodos de Linux.
• Número máximo de pods admitidos por el complemento de Azure Policy por clúster: 10 000
• Número máximo de registros no compatibles por directiva por clúster: 500
• Número máximo de registros no compatibles por suscripción: 1 millón
• Razones para el incumplimiento no están disponibles para el modo de proveedor de recursos Microsoft.Kubernetes.Data . Utilice Detalles del componente.
• No se admiten exenciones a nivel de componente para los modos de proveedor de recursos. La compatibilidad con parámetros está disponible en las definiciones de Azure Policy para excluir e incluir espacios de nombres concretos.
• El uso de la anotación metadata.gatekeeper.sh/requires-sync-data en una plantilla de restricción para configurar la replicación de datos del clúster en la memoria caché de OPA solo se permite actualmente para las directivas integradas. Esto se debe a que puede aumentar drásticamente el uso de recursos de los pods de Gatekeeper si no se usa cuidadosamente.

Configurando la configuración de Gatekeeper

No se admite el cambio de la configuración de Gatekeeper, ya que contiene una configuración de seguridad crítica. Las modificaciones de la configuración se reconcilian.

Uso de data.inventory en plantillas de restricción

En la actualidad, varias directivas integradas utilizan la replicación de datos, que permite a los usuarios sincronizar los recursos existentes en el clúster con la caché de OPA y hacerles referencia durante la evaluación de una solicitud de AdmissionReview. Las directivas de replicación de datos se pueden diferenciar por la presencia de data.inventory en Rego y la presencia de la anotación metadata.gatekeeper.sh/requires-sync-data, que informa al complemento de Azure Policy qué recursos deben almacenarse en caché para que la evaluación de directivas funcione correctamente. Este proceso difiere de Gatekeeper independiente, donde esta anotación es descriptiva, no prescriptiva.

La replicación de datos está actualmente bloqueada para su uso en definiciones de directivas personalizadas, ya que replicar recursos con un elevado número de instancias puede aumentar drásticamente la utilización de recursos de los pods de Gatekeeper si no se usa con cuidado. Verá un error ConstraintTemplateInstallFailed cuando intente crear una definición de directiva personalizada que contenga una plantilla de restricciones con esta anotación.

Puede parecer que la eliminación de la anotación mitiga el error que ve, pero después el complemento de directivas no sincronizará ningún recurso necesario para esa plantilla de restricciones en la caché. De este modo, sus directivas se evaluarán con un data.inventory vacío (suponiendo que no se haya asignado ninguno integrado que replique los recursos necesarios). Esto provocará resultados engañosos de cumplimiento. Como se ha indicado anteriormente, tampoco está permitido editar manualmente la configuración para almacenar en caché los recursos necesarios.

Las limitaciones siguientes solo se aplican al complemento de Azure Policy para AKS:

• AKS Pod security policy y el complemento Azure Policy para AKS no se pueden habilitar. Para obtener más información, consulte Limitación de seguridad de pod de AKS.
• Los espacios de nombres que el complemento de Azure Policy excluye automáticamente para la evaluación: kube-system y gatekeeper-system.

Preguntas más frecuentes

¿Qué despliega en mi clúster la extensión o complemento de Azure Policy tras la instalación?

El complemento de Azure Policy requiere que se ejecuten tres componentes de Gatekeeper: un pod de auditoría y dos réplicas de pod de webhook. También se instala un pod de Azure Policy y otro de Azure Policy webhook.

¿Cuánto consumo de recursos debo esperar que use el complemento o la extensión de Azure Policy en cada clúster?

El "Azure Policy" para los componentes de Kubernetes que se ejecutan en el clúster consume más recursos a medida que aumenta el número de recursos de Kubernetes y las asignaciones de políticas en el clúster, lo que requiere operaciones de auditoría y cumplimiento.

A continuación se indican estimaciones que le ayudarán en su plan:

• Para menos de 500 pods en un solo clúster con un máximo de 20 restricciones: dos vCPU y 350 MB de memoria por componente.
• Para más de 500 pods en un solo clúster con un máximo de 40 restricciones: tres vCPUs y 600 MB de memoria por componente.

¿Se pueden aplicar Azure Policy para las definiciones de Kubernetes en pods de Windows?

Windows pods no admiten contextos de seguridad. Por lo tanto, algunas de las definiciones de Azure Policy, como no permitir privilegios raíz, no se pueden escalar en pods de Windows y solo se aplican a los pods de Linux.

¿Qué tipo de datos de diagnóstico recopila la extensión Azure Policy?

El complemento de Azure Policy para Kubernetes recopila datos de diagnóstico de clúster limitados. Estos datos de diagnóstico son datos técnicos esenciales relacionados con el software y el rendimiento. Los datos se usan de las siguientes maneras:

• Mantenga el complemento de Azure Policy actualizado.
• Mantenga el complemento de Azure Policy seguro, confiable y de alto rendimiento.
• Mejorar el complemento de Azure Policy mediante el análisis agregado del uso del complemento.

La información recopilada por el complemento no son datos personales. Actualmente se recopilan los detalles siguientes:

• Azure Policy versión del agente de complemento
• Tipo de clúster
• Región del clúster
• Grupo de recursos del clúster
• Identificador de recurso del clúster
• Identificador de suscripción del clúster
• Sistema operativo del clúster (ejemplo: Linux)
• Ciudad del clúster (ejemplo: Seattle)
• Estado o provincia del clúster (ejemplo: Washington)
• País o región del clúster (ejemplo: Estados Unidos)
• Excepciones o errores detectados por el complemento Azure Policy durante la instalación del agente en la evaluación de directivas
• Número de definiciones de políticas de Gatekeeper no instaladas por el complemento de Azure Policy

¿Cuáles son los procedimientos recomendados generales que se deben tener en cuenta al instalar el complemento de Azure Policy?

• Use el grupo de nodos del sistema con el valor taint CriticalAddonsOnly para programar pods de Gatekeeper. Para obtener más información, consulte Uso de grupos de nodos del sistema.
• Proteja el tráfico saliente de sus clústeres de AKS. Para obtener más información, consulte Control del tráfico de salida de los nodos de clúster.
• Si el clúster tiene aad-pod-identity activado, los pods de Node Managed Identity (NMI) modifican los nodos iptables para interceptar las llamadas al punto de conexión de metadatos de instancia de Azure. Esta configuración hace que NMI intercepte toda solicitud realizada al punto de conexión de Metadata, incluso aunque el pod no utilice aad-pod-identity.
• La CRD de AzurePodIdentityException se puede configurar para informar a aad-pod-identity de que las solicitudes dirigidas al punto de conexión de Metadata que se originen en un pod que coincida con las etiquetas definidas en la CRD deban pasar por el servidor proxy sin que se procesen en NMI. Los pods del sistema que tienen la etiqueta kubernetes.azure.com/managedby: aks del espacio de nombres kube-system se deben excluir en aad-pod-identity mediante la configuración de la CRD de AzurePodIdentityException. Para más información, consulte este artículo acerca de cómo deshabilitar aad-pod-identity en una aplicación o pod específicos. Para configurar una excepción, instale el mic-exception YAML.

Pasos siguientes

• Revise los ejemplos en Azure Policy samples.
• Vea la Estructura de definición de Azure Policy.
• Vea la Descripción de los efectos de directivas.
• Obtenga información acerca de cómo se pueden crear directivas mediante programación.
• Obtenga información sobre cómo obtener datos de cumplimiento.
• Obtenga información sobre cómo corregir recursos no compatibles.
• Revise qué es un grupo de administración con Organice los recursos con grupos de administración de Azure.