Publicación publicada originalmente en el blog de Kubewarden por Raul Cabello Martin
Hasta ahora, la única forma de definir una política en Kubewarden era usar una ClusterAdmissionPolicy
que se aplica a los recursos de todo el clúster en todos los espacios de nombres.
Es por eso que estamos que se anuncia el nuevo AdmissionPolicy
recurso. Este nuevo recurso se crea dentro de namespace
y las políticas procesarán solo las solicitudes que se dirigen al espacio de nombres donde AdmissionPolicy
está definido. Excepto por ser un recurso de "espacio de nombres", AdmissionPolicy
funciona exactamente igual que ClusterAdmissionPolicy
.
¿Por qué debería usar AdmissionPolicies?
Es posible restringir los espacios de nombres en los que ClusterAdmissionPolicy
evalúa los recursos mediante un archivo namespaceSelector
. Sin embargo, no hay forma de que los administradores de Kubernetes restrinjan a los usuarios la creación de ClusterAdmissionPolicies
recursos de evaluación solo en un espacio de nombres en particular.
Permitir que todos los inquilinos implementen ClusterAdmissionPolicies
es arriesgado. Un arrendatario podría aplicar políticas que afecten a los recursos en todos los espacios de nombres, incluso si no tiene acceso a todos ellos. Probablemente desee permitir que los inquilinos implementen políticas solo en los espacios de nombres a los que tienen acceso. ¡Ahí es donde AdmissionPolicies
entra en juego! Podemos lograr esta restricción con un Control AdmissionPolicies
de acceso basado en roles (RBAC) en Kubernetes .
Como ejemplo, supongamos que desea un arrendatario que pueda implementar recursos solo en el espacio de development
nombres. Puede permitir que este arrendatario se implemente AdmissionPolicies
solo en este espacio de nombres mediante RBAC. Sin embargo, si les permitió crear ClusterAdmissionPolicies
, podrían bloquear otros recursos para que no se manejen en otros espacios de nombres.
¡Política de admisión en acción!
Vamos a crear uno AdmissionPolicy
que rechace la creación de pods privilegiados en el espacio de production
nombres. Para este ejemplo, se requiere un clúster de Kubernetes con Kubewarden ya instalado. El proceso de instalación se describe en la guía de inicio rápido .
Primero, cree dos espacios de nombres: development
yproduction
kubectl create ns development nkubectl create ns productionn
Una vez que se crean los espacios de nombres, cree un nuevo AdmissionPolicy
recurso en el espacio de production
nombres:
apiVersion: policies.kubewarden.io/v1alpha2nkind: AdmissionPolicynmetadata:n name: ns-privileged-podsn namespace: productionnspec:n module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.1.9n rules:n - apiGroups: [""]n apiVersions: ["v1"]n resources: ["pods"]n operations:n - CREATEn mutating: falsenn
Espere a que la política esté activa:
kubectl wait --for=condition=PolicyActive admissionpolicies ns-privileged-pods -n productionn
Cree un archivo denominado privileged-pod.yaml
con la siguiente especificación de pod:
apiVersion: v1nkind: Podnmetadata:n name: privileged-podnspec:n containers:n - name: nginxn image: nginx:latestn securityContext:n privileged: truen
Intente crear un pod privilegiado en el espacio de production
nombres:
kubectl apply -f privileged-pod.yaml -n productionn
Obtendrá el siguiente error:
Error from server: error when creating "privileged-pod.yaml": admission webhook "namespaced-kubewarden-privileged-pods.kubewarden.admission" denied the request: User 'my-user' cannot schedule privileged containersn
Finalmente, verifique que pueda crear correctamente un pod privilegiado en un espacio de nombres diferente:
kubectl apply -f privileged-pod.yaml -n developmentn
Conclusión
Como se evidencia en el ejemplo anterior, Kubewarden le ofrece dos opciones diferentes para implementar políticas.
Si su política debe aplicarse a recursos en todos los espacios de nombres o recursos de todo el clúster, entonces puede usar ClusterAdmissionPolicies
.
Por otro lado, si su clúster es compartido por varios usuarios o equipos, utiliza diferentes espacios de nombres o su política debe aplicarse solo a los recursos dentro de un espacio de nombres, entonces la nueva AdmissionPolicy
sería la opción correcta.
Puede encontrar la AdmissionPolicy
especificación aquí .
Como comunidad, nos esforzamos por recibir comentarios y agradecemos sus sugerencias. ¡ No dude en abrir un problema en nuestro repositorio de GitHub o ponerse en contacto en el canal de Slack #kubewarden !