Protección de los clústeres de Azure Kubernetes Service (AKS) con Azure Policy

Artículo
08/02/2024

Puedes aplicar y hacer cumplir directivas de seguridad integradas en tus clústeres de Azure Kubernetes Service (AKS) mediante Azure Policy. Azure Policy ayuda a hacer cumplir los estándares de la organización y evalúa el cumplimiento a escala. Después de instalar el complemento de Azure Policy para AKS, puedes aplicar definiciones de directivas individuales o grupos de definiciones de directivas denominadas iniciativas (a veces denominadas conjuntos de directivas) a tu clúster. Para ver una lista completa de definiciones de directiva e iniciativa de AKS, consulte Definiciones integradas de Azure Policy para Azure Kubernetes Service.

En este artículo se muestra cómo aplicar definiciones de directiva al clúster y comprobar que se aplican esas asignaciones.

Requisitos previos

Este artículo supone que ya tiene un clúster de AKS. Si necesitas un clúster de AKS, puedes crear uno mediante la CLI de Azure, Azure PowerShell o Azure Portal.
Necesitas el complemento de Azure Policy para AKS instalado en el clúster de AKS.

Asignación de una definición o iniciativa de directiva integrada

Puedes aplicar una definición o iniciativa de directiva en el Azure Portal mediante los pasos siguientes:

Navega hasta el servicio de Azure Policy en Azure Portal denominado Directiva.
En el panel izquierdo de la página de Azure Policy, seleccione Definitions (Definiciones).
En Categorías, selecciona Kubernetes.
Elija la definición o iniciativa de directiva que quiera aplicar. Para este ejemplo, selecciona los estándares de referencia de seguridad del módulo de clúster de Kubernetes para la iniciativa de cargas de trabajo basadas en Linux.
Seleccione Asignar.
Establece el valor de Ámbito en el grupo de recursos del clúster de AKS con el complemento de Azure Policy habilitado.
Seleccione la página Parámetros y actualice Efecto de audit a deny para impedir que las nuevas implementaciones infrinjan la iniciativa de línea de base. También puedes agregar espacios de nombres adicionales para excluirlos de la evaluación. En este ejemplo, conserve los valores predeterminados.
Selecciona Revisar + crear>Crear para enviar la asignación de directivas.

Creación y asignación de una definición de directiva personalizada

Las directivas personalizadas permiten definir reglas para usar Azure. Por ejemplo, puedes aplicar los siguientes tipos de reglas:

Prácticas de seguridad
Administración de costos
Reglas específicas de la organización (como nombres o ubicaciones)

Antes de crear una directiva personalizada, compruebe la lista de patrones y ejemplos comunes para ver si ya incluye su caso.

Las definiciones de directivas personalizadas se escriben en JSON. Para más información sobre cómo crear una directiva personalizada, consulte Estructura de definición de Azure Policy y Creación de una definición de directiva personalizada.

Nota

Azure Policy ahora utiliza una nueva propiedad conocida como templateInfo que te permite definir el tipo de fuente para la plantilla de restricción. Cuando defines templateInfo en las definiciones de directivas, no tienes que definir las propiedades de constraintTemplate o define. No obstante, tienes que definir apiGroups y kinds. Para más información, consulte Descripción de los efectos de Azure Policy.

Una vez que hayas creado tu definición de directiva personalizada, consulta Asignar una definición de directiva para obtener un tutorial paso a paso sobre cómo asignar la directiva al clúster de Kubernetes.

Validar que se está ejecutando Azure Policy

Confirma que las asignaciones de directivas se aplican al clúster mediante el siguiente comando kubectl get.

kubectl get constrainttemplates

Nota

Las asignaciones de directivas pueden tardar hasta 20 minutos en sincronizarse con cada clúster.

La salida debe ser similar a la siguiente salida de ejemplo:

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

Validación del rechazo de un pod con privilegios

Vamos a probar primero lo que sucede cuando se programa un pod con el contexto de seguridad privileged: true. Este contexto de seguridad eleva los privilegios del pod. La iniciativa no permite los pods privilegiados, por lo que se deniega la solicitud, lo que provoca que se rechace la implementación.

Cree un archivo denominado nginx-privileged.yaml y pegue el siguiente manifiesto de YAML.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        privileged: true

Cree el pod con el comando kubectl apply y especifique el nombre de su manifiesto de YAML.

kubectl apply -f nginx-privileged.yaml

Como se esperaba, el pod no se puede incluir en la programación, como se muestra en la salida del ejemplo siguiente:

Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}

El pod no llega a la fase de programación, por lo que no hay recursos que eliminar para continuar.

Prueba de la creación de un pod sin privilegios

En el ejemplo anterior la imagen de contenedor intentó automáticamente utilizar la raíz para enlazar NGINX al puerto 80. La iniciativa de directiva deniega esta solicitud, por lo que el pod no se inicia. Ahora, intentemos ejecutar ese mismo pod NGINX sin acceso privilegiado.

Cree un archivo denominado nginx-unprivileged.yaml y pegue el siguiente manifiesto de YAML.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine

Cree el pod con el comando kubectl apply y especifique el nombre de su manifiesto de YAML.
```
kubectl apply -f nginx-unprivileged.yaml
```
Compruebe el estado del pod con el comando kubectl get pods.
```
kubectl get pods
```
Tu salida debe ser similar a la siguiente salida de ejemplo, que muestra que el pod se programó correctamente y tiene un estado de En ejecución:
```
NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          18s
```
Este ejemplo muestra la iniciativa de referencia que afecta solo a las implementaciones que infringen las directivas de la colección. Las implementaciones permitidas continúan funcionando.
Elimine el pod NGIX sin privilegios mediante el comando kubectl delete y especifique el nombre del manifiesto de YAML.
```
kubectl delete -f nginx-unprivileged.yaml
```

Deshabilitación de una directiva o iniciativa

Puedes quitar la iniciativa de línea base en el Azure Portal mediante los pasos siguientes:

Ve al panel Directiva en Azure Portal.
Seleccione Asignaciones.
Seleccione el botón... junto a los estándares de referencia de seguridad del módulo de clúster de Kubernetes para la iniciativa de carga de trabajo basada en Linux.
Seleccione Eliminar asignación.

Pasos siguientes

Para obtener más información sobre cómo funciona Azure Policy, consulta los siguientes artículos:

Compartir a través de