Leer en inglés

Compartir a través de

Descripción de Azure Policy para clústeres de Kubernetes (versión preliminar)

  • Artículo

Azure Policy amplía Gatekeeper v3, un webhook de controlador de admisión de Open Policy Agent (OPA), a fin de aplicar medidas de seguridad y cumplimiento a escala en los componentes del clúster de una manera 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 único lugar. Mediante el complemento o la extensión de Azure Policy, la regulación de los componentes del clúster se mejora con las características de Azure Policy, como la capacidad de usar selectores e invalidaciones para la implementación y reversión de directivas seguras.

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

Importante

El modelo de Helm del complemento de Azure Policy y el complemento para el motor de AKS han quedado en desuso. Siga las instrucciones para quitar los complementos.

Información general

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

  • Comprueba con el servicio Azure Policy las asignaciones de directivas al 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).
  • Realiza informes de auditoría y cumplimiento y los devuelve al servicio Azure Policy.

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

  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 resolver problemas de instalación comunes, consulte el tema de solución de problemas del complemento de Azure Policy.

  2. Creación o uso de 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

Instalación del complemento de Azure Policy para AKS

El complemento de Azure Policy para AKS forma parte de la versión 1.27 de Kubernetes con soporte 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:

      Azure CLI 
      # 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. Es preciso que esté instalada y configurada la versión 2.12.0 de la CLI de Azure, o cualquier otra posterior. Para encontrar la versión, ejecute el comando az --version. Si tiene que instalar o actualizar la CLI, consulte Instalación de la 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:

    Azure CLI 
    # Log in first with az login if you're not using Cloud Shell

# Look for the value in kubernetesVersion
az aks list

  4. Abra los puertos para la extensión de Azure Policy. La extensión de Azure Policy usa estos dominios y puertos para obtener las definiciones de directiva y las asignaciones, así como para notificar a Azure Policy el cumplimiento del clúster.

    Domain Port
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443

Tras completar los requisitos previos, instale el complemento de Azure Policy en el clúster de AKS que quiera administrar.

  • Azure portal

    1. Inicie el servicio AKS en Azure Portal al seleccionar Todos los servicios; a continuación, busque y seleccione Servicios de Kubernetes.

    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).

  • Azure CLI

    Azure CLI 
    # 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:

Bash 
# 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, para comprobar que el complemento más reciente está instalado, ejecute este comando de la CLI de Azure y reemplace <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 resultado para los clústeres que usan entidades de servicio:

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

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

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

Instalación de la extensión de Azure Policy para Kubernetes habilitado para Azure Arc

Azure Policy para Kubernetes permite administrar e informar sobre el estado de cumplimiento de los clústeres de Kubernetes desde un único 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 Azure Policy para Kubernetes.

Para obtener información general sobre la plataforma de extensiones, vea las 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 eliminar el gráfico de Helm. Tras realizar la eliminación, puede continuar.

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

    Nota

    La extensión Azure Policy para Arc es compatible con las siguientes distribuciones de Kubernetes.

  2. Asegúrese de que ha cumplido todos los requisitos previos comunes para las extensiones de Kubernetes enumeradas aquí, incluida la conexión del clúster a Azure Arc.

    Nota

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

  3. Abra los puertos para la extensión de Azure Policy. La extensión de Azure Policy usa estos dominios y puertos para obtener las definiciones de directiva y las asignaciones, así como para notificar a Azure Policy el cumplimiento del clúster.

    Domain Port
    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 de Azure Policy o habilitar cualquiera de las características del servicio, la suscripción debe habilitar los proveedores de recursos Microsoft.PolicyInsights.

    Nota

    Para habilitar el proveedor de recursos, siga los pasos descritos en Tipos y proveedores de recursos o ejecute el comando de Azure PowerShell o de la CLI de Azure.

    • CLI de Azure

      Azure CLI 
      # 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

      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 la extensión de Azure Policy

Nota

Tenga en cuenta lo siguiente para crear la extensión de Azure Policy:

  • La actualización automática está habilitada de forma predeterminada, lo que actualizará la versión secundaria de la extensión de Azure Policy si se implementa cualquier cambio nuevo.
  • Las variables de proxy pasadas como parámetros a connectedk8s se propagarán a la extensión de Azure Policy para admitir el proxy de salida.

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

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

Ejemplo:

Azure CLI 
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:

JSON 
{
  "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"
}

Visualización de la 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:

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

Ejemplo:

Azure CLI 
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:

Bash 
# 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

Eliminación de la extensión de Azure Policy

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

Azure CLI 
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 del lenguaje de Azure Policy para administrar Kubernetes sigue la de las definiciones de directiva existentes. Hay archivos de definición de ejemplo disponibles para asignar en la biblioteca de directivas integrada de Azure Policy que se puede usar para controlar los componentes del clúster.

Azure Policy para Kubernetes también admite la creación de definiciones personalizadas en el 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 Visual Studio Code de Azure Policy se puede usar para ayudar a traducir una plantilla de restricción existente o una plantilla de mutación a una definición de directiva de Azure Policy personalizada.

Con un modo de proveedor de recursos de Microsoft.Kubernetes.Data, se usan los efectos audit, deny, disabled y mutate 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 de la definición de directiva, Azure Policy pasa los URI o valores Base64Encoded de estas CustomResourceDefinitions (CRD) al complemento. Rego es el lenguaje que OPA y el equipo selector admiten para validar una solicitud al clúster de Kubernetes. Al admitir un estándar existente para la administración de Kubernetes, Azure Policy le permite reutilizar las reglas existentes y vincularlas con Azure Policy para obtener una experiencia de informes de cumplimiento unificada 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 al clúster de Kubernetes, debe tener asignadas las operaciones de asignación de directivas de control de acceso basado en rol de Azure (RBAC de AZure) adecuadas. Los roles de Azure integrados Colaborador de la directiva de recursos y Propietario tienen estas operaciones. Para obtener más información, vea Permisos de RBAC de Azure en Azure Policy.

Siga estos pasos para buscar las directivas integradas para administrar el clúster mediante Azure Portal. 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 Azure Portal. 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 (Definiciones).

  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 Azure Policy para la definición de Kubernetes, el Ámbito 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 con 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 directivas, especifique la lista de espacios de nombres en el parámetro Exclusiones de los 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.

Importante

Las definiciones de directiva integradas están disponibles para los clústeres de Kubernetes en la categoría Kubernetes. Para obtener una lista de las definiciones de directiva integradas, vea Ejemplos de Kubernetes.

Evaluación de directiva

El complemento se registra con el servicio Azure Policy para detectar 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

Nota

Aunque es posible que un administrador de clústeres tenga permiso para crear y actualizar los recursos de plantillas y restricciones instalados por el complemento Azure Policy, estos no son escenarios admitidos, ya que las actualizaciones manuales se sobrescriben. Gatekeeper sigue evaluando las directivas que existían antes de instalar el complemento y de asignar las definiciones de directiva de Azure Policy.

Cada 15 minutos, el complemento solicita un examen completo del clúster. Después de recopilar los detalles del examen completo y las evaluaciones en tiempo real que realiza Gatekeeper sobre los intentos de cambios en el clúster, el complemento proporciona los resultados a Azure Policy para los agregue en los detalles de cumplimiento como cualquier otra 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.

Nota

En cada informe de cumplimiento de Azure Policy para los clústeres de Kubernetes se incluyen todas las infracciones de los últimos 45 minutos. La marca de tiempo indica cuándo se ha producido una infracción.

Otras consideraciones:

  • Si la suscripción del clúster se registra con Microsoft Defender for Cloud, las directivas de Kubernetes de Microsoft Defender for Cloud 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, imagine que tiene una implementación de Kubernetes con 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.

Nota

Los contenedores de inicialización se pueden incluir durante la evaluación de directivas. Para ver si los contenedores de inicialización están incluidos, revise el valor de CRD para la declaración siguiente u otra similar:

rego 
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 template.yaml almacenado en diferentes ubicaciones de origen como, por ejemplo, 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 obtener más información, vea Supervisión del rendimiento del clúster de Kubernetes con Azure Monitor para contenedores.

Para ver los registros del complemento, use kubectl:

Bash 
# 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 descarga las asignaciones de directiva e instala las plantillas de restricción y las restricciones en el clúster, anota ambos 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.

    En el caso de un nuevo clúster de Azure Kubernetes Service, use la siguiente CLI de Azure:

    Azure CLI 
    # 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.

Visualización de las plantillas de restricción 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.

Obtención de 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:

YAML 
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 asignada. <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.

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:

YAML 
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 acerca de cómo solucionar los problemas del complemento de Kubernetes, consulte la sección Kubernetes en el artículo de solución de problemas de Azure Policy.

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

Para problemas relacionados con Azure Policy, vaya a:

Complemento de Azure Policy para el registro de cambios de AKS

El complemento de Azure Policy para AKS tiene un número de versión que indica la versión de 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 a compartir una tabla histórica de la versión del 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 de control de versiones semántico estándar 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 usa, siga las instrucciones de AKS vinculadas.

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

1.10.0

Mejoras de seguridad.

CEL está habilitado de forma predeterminada. La marca de característica ya no es necesaria para habilitar CEL. Se introduce el nuevo CRD configpodstatuses.status.gatekeeper.sh

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

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

1.9.1

Mejoras de seguridad.

Revisión CVE-2024-45337 y CVE-2024-45338.

  • Publicado en enero de 2025
  • Kubernetes 1.27+
  • Gatekeeper 3.17.1
Gatekeeper 3.17.1-5

Revisión CVE-2024-45337 y CVE-2024-45338.

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.

  • Publicado en 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 la marca 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.

  • Publicado en 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.

  • Publicado en julio de 2024
  • Kubernetes 1.27+
  • Gatekeeper 3.16.3

1.6.1

Mejoras de seguridad.

  • Publicado en mayo de 2024
  • Gatekeeper 3.14.2

1.5.0

Mejoras de seguridad.

  • Publicado en 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.

  • Publicada en mayo de 2024
  • Kubernetes 1.25+
  • Gatekeeper 3.14.0

1.3.0

Presenta el estado de error de las directivas en caso de error, lo que les permite distinguirlas de las directivas en estado no conforme. Agrega compatibilidad con las plantillas de restricción v1 y el uso del parámetro excludedNamespaces 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.

  • Publicación en febrero de 2024
  • Kubernetes 1.25+
  • Gatekeeper 3.14.0

1.2.1

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

1.1.0

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

1.0.1

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

1.0.0

Azure Policy para Kubernetes ahora admite la mutación para corregir los clústeres de AKS a escala.

Eliminar el complemento

Eliminación del complemento de AKS

Para eliminar el complemento de Azure Policy del clúster de AKS, use Azure Portal o la CLI de Azure:

  • Azure portal

    1. Inicie el servicio AKS en Azure Portal al seleccionar Todos los servicios; a continuación, busque y seleccione Servicios de Kubernetes.

    2. Seleccione el clúster de AKS en el que quiera 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).

  • Azure CLI

    Azure CLI 
    # 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

Eliminación del complemento desde Kubernetes habilitado para Azure Arc

Nota

El complemento del model Helm de Azure Policy ya está en desuso. En su lugar, debe optar por la extensión de Azure Policy para Kubernetes habilitado para Azure Arc.

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

Bash 
helm uninstall azure-policy-addon

Eliminación del complemento desde AKS Engine

Nota

El producto AKS Engine ya está en desuso para los clientes de la nube pública de Azure. Considere la posibilidad de usar Azure Kubernetes Service (AKS) para Kubernetes administrado o el proveedor de API de clúster de Azure para Kubernetes autoadministrado. No hay nuevas características planeadas; este proyecto solo se actualizará para los CSV y similares, con Kubernetes 1.24 como la versión final para recibir actualizaciones.

Para quitar el complemento de Azure Policy y Gatekeeper del clúster de AKS Engine, use el método en línea con la manera en que se ha instalado 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:

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

    Para obtener más información, vea AKS Engine: deshabilitación del complemento de Azure Policy.

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

    Bash 
    helm uninstall azure-policy-addon

Limitaciones

  • Para conocer las definiciones generales de Azure Policy y los límites de asignación, consulte Límites documentados de Azure Policy
  • El complemento 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
  • No se admiten las instalaciones de Gatekeeper fuera del complemento de Azure Policy. Desinstale los componentes instalados por una instalación anterior de Gatekeeper antes de habilitar el complemento de Azure Policy.
  • Los motivos de incumplimiento no están disponibles para el modo proveedor de recursos de Microsoft.Kubernetes.Data. Use 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 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.

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 el Rego, así como por la presencia de la anotación metadata.gatekeeper.sh/requires-sync-data, que informa al complemento de Azure Policy de los recursos que se deben almacenar en caché para que la evaluación de la directiva 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 siguientes limitaciones generales solo se aplican al complemento de Azure Policy para AKS:

Preguntas más frecuentes

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

El complemento de Azure Policy requiere tres componentes de Gatekeeper para ejecutarse: 1 pod de auditoría y 2 réplicas de pods de webhook. También se instala un pod de Azure Policy y un pod del webhook de Azure Policy.

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

Los componentes de Azure Policy para Kubernetes que se ejecutan en el clúster consumen más recursos a medida que aumenta el recuento de recursos y asignaciones de directivas de Kubernetes 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 vCPU y 600 MB de memoria por componente.

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

Los pods de Windows 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 el complemento de 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:

  • Mantener actualizado el complemento de Azure Policy.
  • Mantener la seguridad, la confiabilidad y el rendimiento del complemento de Azure Policy.
  • 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:

  • Versión del agente del complemento de Azure Policy
  • 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 encontrados por el complemento de Azure Policy durante la instalación del agente en la evaluación de directiva
  • Número de definiciones de directiva 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 pods 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 habilitado, los pods de Identidad administrada del nodo (NMI) modifican los nodos iptables para interceptar las llamadas que se realizan al punto de conexión de Azure Instance Metadata. 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 obtener 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 mic-exception.YAML.

Pasos siguientes