Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Esta es documentación inédita para Admission Controller 1.34-dev.

Inicio rápido

El SUSE Security Admission Controller stack se compone de:

  • Uno o más recursos de ClusterAdmissionPolicy: esto define políticas para los clusters de Kubernetes.

  • Uno o más recursos de PolicyServer: representando una ampliación de un Admission Controller PolicyServer. El Admission Controller PolicyServer carga y evalúa las políticas de tu administrador.

  • Uno o más recursos de AdmissionPolicy: políticas para un espacio de nombres definido.

  • Una ampliación de un kubewarden-controller: este controlador monitoriza los recursos de ClusterAdmissionPolicy e interactúa con los componentes Admission Controller PolicyServer.

Admission Controller describe sus definiciones de recursos personalizadas (CRDs) de Kubernetes aquí.

Los CRDs de Admission Controller mencionados en este tutorial y en el resto de la documentación tienen nombres cortos, que son más fáciles de usar. Estos son los nombres cortos para los CRDs:

Recurso nombreCorto

AdmissionPolicies

ap

ClusterAdmissionPolicies

cap

AdmissionPolicyGroups

apg

ClusterAdmissionPolicyGroups

capg

PolicyServers

ps

Instalación

Autenticación

Puedes recuperar políticas de Admission Controller del registro de contenedores de GitHub en https://ghcr.io.. Necesitas autenticación para usar el repositorio con la CLI Admission Controller, un token de acceso personal de GitHub (PAT). Su documentación te guía a través de la creación de uno si aún no lo has hecho. Luego te autenticas con un comando como:

echo $PAT | docker login ghcr.io --username <my-gh-username> --password-stdin

Despliega la pila Admission Controller utilizando los gráficos helm de la siguiente manera:

helm repo add kubewarden https://charts.kubewarden.io
helm repo update kubewarden

Instala los siguientes gráficos de Helm en el espacio de nombres kubewarden en tu clúster de Kubernetes:

  • kubewarden-crds, que registra las definiciones de recursos personalizadas ClusterAdmissionPolicy, AdmissionPolicy y PolicyServer. Además, las definiciones de recursos personalizadas {report} utilizadas por el escáner de auditoría.

  • kubewarden-controller, que instala el controlador Admission Controller y el escáner de auditoría.

    Si necesitas deshabilitar el componente del escáner de auditoría, consulta la página de documentación de instalación del escáner de auditoría.

  • kubewarden-defaults, que crea un recurso PolicyServer llamado default. También puede instalar un conjunto de políticas recomendadas para asegurar tu clúster aplicando buenas prácticas bien conocidas.

helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds
helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller
helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

Dado que v0.4.0, no se crea un recurso PolicyServer llamado default utilizando el gráfico kubewarden-controller. Ahora un gráfico de Helm llamado kubewarden-defaults instala el servidor de políticas por defecto.

Esto significa que si no utilizas la última versión del kubewarden-controller al actualizar versión o eliminar, tu servidor de políticas por defecto no se actualiza ni se elimina. Por lo tanto, podrías encontrarte con problemas si intentas instalar el kubewarden-defaults con información conflictiva, por ejemplo, el mismo nombre de servidor de políticas. Para instalar futuras actualizaciones del Helm chart kubewarden-defaults, eliminar el recurso PolicyServer existente creado por el kubewarden-controller antes de instalar el nuevo chart. Ahora puedes actualizar la versión de tu servidor de políticas utilizando actualizaciones de Helm sin conflictos de recursos. Cuando eliminas el PolicyServer, también eliminas todas las políticas vinculadas a él.

Los valores de configuración predeterminados son suficientes para la mayoría de las ampliaciones. La documentación describe todas las opciones.

Componentes principales

Admission Controller tiene tres componentes principales con los que interactúas:

PolicyServer

El kubewarden-controller gestiona un Admission Controller PolicyServer. Puedes desplegar múltiples PolicyServers en el mismo clúster de Kubernetes.

Un PolicyServer valida las solicitudes entrantes ejecutando Admission Controller políticas contra ellas.

Esta es la configuración por defecto del PolicyServer:

apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
  name: reserved-instance-for-tenant-a
spec:
  image: ghcr.io/kubewarden/policy-server:v1.3.0
  replicas: 2
  serviceAccountName: ~
  env:
    - name: KUBEWARDEN_LOG_LEVEL
      value: debug

Consulta el última versión PolicyServer lanzada y cambia la etiqueta para que coincida.

Resumen de los atributos del recurso PolicyServer:

required Espacio reservado Descripción

S

image

El nombre de la imagen del contenedor

S

replicas

El número de instancias deseadas

D

serviceAccountName

El nombre del ServiceAccount que se utilizará para la ampliación de PolicyServer. Si no se proporciona un valor, se utiliza el ServiceAccount por defecto del espacio de nombres de instalación, de kubewarden-controller.

D

env

La lista de variables de entorno

D

annotations

La lista de anotaciones

Cambiar cualquiera de estos atributos provoca una ampliación de PolicyServer con la nueva configuración.

ClusterAdmissionPolicy

El recurso ClusterAdmissionPolicy es el núcleo de la pila Admission Controller. Define cómo las políticas evalúan las solicitudes.

Hacer cumplir políticas es la operación más común que realiza un administrador de Kubernetes. Puedes declarar tantas políticas como desees, cada una de las cuales apunta a uno o más recursos de Kubernetes (es decir, pods, Custom Resource y otros). También especificas el tipo de operaciones aplicadas a los recursos objetivo. Las operaciones disponibles son CREATE, UPDATE, DELETE y CONNECT.

Configuración por defecto ClusterAdmissionPolicy:

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  policyServer: reserved-instance-for-tenant-a
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.9
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
      - CHOWN
    required_drop_capabilities:
      - NET_ADMIN

Resumen de los atributos del recurso ClusterAdmissionPolicy:

required Espacio reservado Descripción

D

policy-server

Identifica un objeto PolicyServer existente. Solo esta instancia PolicyServer sirve a la política. El servidor de políticas llamado default sirve un ClusterAdmissionPolicy sin un PolicyServer explícito.

S

module

La ubicación de la política Admission Controller. Se permiten los siguientes esquemas:

D

- registry: Descarga de políticas desde un registro de contenedores compatible con OCI artifacts. Ejemplo: registry://<OCI registry/policy URL>

D

- http, https: Descarga de políticas desde un servidor HTTP(s) regular. Ejemplo: https://<website/policy URL>

D

- file: Carga la política desde un archivo en el sistema de archivos. Ejemplo: file:///<policy WASM binary full path>

S

resources

Los recursos de Kubernetes evaluados por la política

S

operations

Qué operaciones para los tipos dados anteriormente deben ser reenviadas a esta política de admisión por el servidor API para su evaluación.

S

mutating

Establece este valor booleano true para políticas que pueden mutar las solicitudes entrantes

D

settings

Un objeto de forma libre que contiene los valores de configuración de la política

D

failurePolicy

La acción a tomar si la solicitud evaluada por una política resulta en un error. Se permiten las siguientes opciones:

D

- Ignore: ignora un error al llamar al webhook y la solicitud de API continúa.

D

- Fail: un error al llamar al webhook provoca que la admisión falle y se rechace la solicitud de API.

El controlador registra el webhook de recursos ClusterAdmissionPolicy * scope. Esto significa que los webhooks registrados reenvían todas las solicitudes que coinciden con el resources y operations dados, ya sean recursos a nivel de espacio de nombres o a nivel de clúster.

AdmissionPolicy

AdmissionPolicy es un recurso a nivel de espacio de nombres. La política procesa solo las solicitudes que están dirigidas al espacio de nombres con el AdmissionPolicy definido. Aparte de eso, no hay diferencias funcionales entre los recursos AdmissionPolicy y ClusterAdmissionPolicy.

AdmissionPolicy requiere Kubernetes 1.21.0 o superior. Esto se debe a que Admission Controller utiliza la etiqueta kubernetes.io/metadata.name, introducida en Kubernetes 1.21.0.

La documentación completa de estos Recursos Personalizados está aquí o en docs.crds.dev.

Ejemplo: Aplica tu primera política

Usaremos la política pod-privileged. Queremos prevenir la creación de contenedores privilegiados dentro de nuestro clúster de Kubernetes aplicando esta política.

Definamos un ClusterAdmissionPolicy para hacer eso:

kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.2
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
EOF

Esto produce la siguiente salida:

clusteradmissionpolicy.policies.kubewarden.io/privileged-pods created

Después de instanciar un ClusterAdmissionPolicy, el estado se convierte en pending, y fuerza una ampliación del PolicyServer objetivo. En el ejemplo, es el PolicyServer llamado default. Puedes monitorear la ampliación ejecutando el siguiente comando:

kubectl get clusteradmissionpolicy.policies.kubewarden.io/privileged-pods

Deberías ver la siguiente salida:

NAME              POLICY SERVER   MUTATING   STATUS
privileged-pods   default         false      pending

Una vez que la nueva política esté lista, el kubewarden-controller registra un objeto ValidatingWebhookConfiguration para servirlo.

El estado ClusterAdmissionPolicy se convierte en active una vez que se completa la ampliación para cada instancia PolicyServer. Muestra ValidatingWebhookConfigurations con el siguiente comando:

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l kubewarden

Deberías ver la siguiente salida:

NAME                          WEBHOOKS   AGE
clusterwide-privileged-pods   1          9s

Una vez que el ClusterAdmissionPolicy está activo y el ValidatingWebhookConfiguration se registra, puedes probar la política.

Primero, puedes crear un Pod con un Contenedor no en modo privileged:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

Esto produce la siguiente salida:

pod/unprivileged-pod created

El Pod se ha creado con éxito.

Ahora, puedes crear un Pod con al menos una bandera de Contenedor privileged:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
          privileged: true
EOF

La política niega la creación del Pod y deberías ver el siguiente mensaje:

Error from server: error when creating "STDIN": admission webhook "clusterwide-privileged-pods.kubewarden.admission" denied the request: Privileged container is not allowed

Ambos ejemplos no definieron un namespace, lo que significa que el espacio de nombres default fue el objetivo. Sin embargo, como pudiste ver en el segundo ejemplo, la política sigue aplicándose. Como se indicó anteriormente, esto se debe a que el alcance es a nivel de clúster y no está dirigido a un espacio de nombres específico.

Desinstalación

Puedes eliminar los recursos creados desinstalando los gráficos de helm de la siguiente manera:

helm uninstall --namespace kubewarden kubewarden-defaults
helm uninstall --namespace kubewarden kubewarden-controller
helm uninstall --namespace kubewarden kubewarden-crds

Después de la eliminación de los charts de helm, elimina el espacio de nombres de Kubernetes utilizado para desplegar la pila Admission Controller:

kubectl delete namespace kubewarden

Admission Controller contiene un gancho pre-eliminación de helm que elimina todos los PolicyServer`s y `kubewarden-controller`s. Luego, el `kubewarden-controller elimina todos los recursos, por lo que es importante que el kubewarden-controller esté en funcionamiento cuando se ejecute helm uninstall.

Admission Controller elimina ValidatingWebhookConfigurations y MutatingWebhookConfigurations. Verifica esto con:

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"

Si estos recursos no se eliminan automáticamente, elimínalos manualmente utilizando el siguiente comando:

kubectl delete -l "kubewarden" validatingwebhookconfigurations.admissionregistration.k8s.io
kubectl delete -l "kubewarden" mutatingwebhookconfigurations.admissionregistration.k8s.io

Concluyendo

ClusterAdmissionPolicy es el recurso kernel que un operador de clúster tiene que gestionar. El módulo kubewarden-controller se encarga automáticamente de la configuración para el resto de los recursos necesarios para ejecutar las políticas.

Pasos siguientes

¡Ahora estáis listos para desplegar Admission Controller! Echad un vistazo a las políticas en artifacthub.io, en GitHub, o reutilizad políticas Rego existentes como se muestra en los capítulos siguientes.

Lista completa de políticas disponibles en ArtifactHub