¿Estás visitando desde Perú?
Ingresá a Linware Perú ⯈
Continuar en Linware Perú ⯈
×
¿Qué estás buscando?
BUSCAR!
BLOG
Introducción a la política de admisión
Publicada el 21/03/2022

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 ClusterAdmissionPolicyque 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 AdmissionPolicyrecurso. Este nuevo recurso se crea dentro de namespacey las políticas procesarán solo las solicitudes que se dirigen al espacio de nombres donde AdmissionPolicyestá definido. Excepto por ser un recurso de "espacio de nombres", AdmissionPolicyfunciona exactamente igual que ClusterAdmissionPolicy.

¿Por qué debería usar AdmissionPolicies?

Es posible restringir los espacios de nombres en los que ClusterAdmissionPolicyevalú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 ClusterAdmissionPoliciesrecursos de evaluación solo en un espacio de nombres en particular.

Permitir que todos los inquilinos implementen ClusterAdmissionPolicieses 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 AdmissionPoliciesentra en juego! Podemos lograr esta restricción con un Control AdmissionPoliciesde acceso basado en roles (RBAC) en Kubernetes .

Como ejemplo, supongamos que desea un arrendatario que pueda implementar recursos solo en el espacio de developmentnombres. Puede permitir que este arrendatario se implemente AdmissionPoliciessolo 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 AdmissionPolicyque rechace la creación de pods privilegiados en el espacio de productionnombres. 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: developmentyproduction

kubectl create ns development nkubectl create ns productionn

Una vez que se crean los espacios de nombres, cree un nuevo AdmissionPolicyrecurso en el espacio de productionnombres:

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.yamlcon 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 productionnombres:

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 AdmissionPolicysería la opción correcta.

Puede encontrar la AdmissionPolicyespecificació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 !

Ir al Blog