En este caso, el Pod de la imagen debe ejecutar en modo no privilegiado, utilizando el usuario de Linux con UID 1001.

En éste último caso, el contexto se define a nivel de contenedor dentro del Pod y nuevamente configura un UID específico de ejecución así también como una capacidad particular de Linux a incorporar.

Pod Security Standards (PSS) and Pod Security Admission (PSA)

De acuerdo a la definición formal que brinda Kubernetes, el PSS “define tres políticas distintas para cubrir ampliamente el espectro de seguridad. Éstas políticas son acumulables y van desde altamente permisivas hasta altamente restrictivas.”

Éstas políticas se definen de la siguiente manera:

• Privileged: no hay restricción alguna, permitiendo el mayor nivel de permisos posibles. Es común utilizarlo en casos de agentes de logs, CNIs, drivers de almacenamiento.
• Baseline: Restricción mínima que previene escaladas de privilegios conocidas. Acepta la configuración que viene por defecto en un Pod. Por otro lado, prohibe el uso de hostNetwork, hostPID, hostIPC, hostPath, hostPort, la incapacidad de agregar capacidades de Linux, y algunas otras restricciones extras.
• Restricted: Restricción fuerte, consideradas las mejores prácticas para Pod hardening. Agrega algunas restricciones a la baseline como la incapacidad de correr con id de usuario o grupo privilegiado. Cuidado ya que algunas restricciones pueden impactar en la ejecución básica de las aplicaciones. Son específicamente útiles para aplicaciones de seguridad críticas.

Ahora bien, estas políticas de seguridad definen tres perfiles de ejecución de Pods, ordenados por niveles de privilegio vs restricción de acceso.

Para implementar estos controles definidos por el PSS, el control de admisión PSA opera en tres modos:

• enforce: Violaciones de las políticas harán que el Pod sea rechazado y por ende, no creado.
• audit: Violaciones de las políticas dispararán una anotación en el evento registrado en el log de auditoría. Pero de todas formas son permitidas.
• warn: Violaciones de las políticas mostrarán una advertencia de cara al usuario, pero de todas formas son permitidas.

Éstos modos, junto con el perfil o restriccion que atacan, son configurados a nivel de Kubernetes Namespace, para lo cual se utilizarán labels o etiquetas, como se ve en el siguiente ejemplo:

apiVersion: v1 
kind: Namespace 
metadata:   
  name: my-namespace   
  labels: 
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted     
    pod-security.kubernetes.io/warn: restricted

Éste sería un escenario de extrema seguridad, donde se fuerza el rechazo de Pods que no cumplan con las políticas mas severas, así como también se audita y se notifica al usuario para tomar acción en forma inmediata.

Para el siguiente escenario:

apiVersion: v1
kind: Namespace
metadata:
 name: my-namespace
 labels:
   pod-security.kubernetes.io/enforce: baseline
   pod-security.kubernetes.io/warn: restricted

No se presenta un nivel de rechazo fuerte (sólo debería cumplir con políticas de base), pero si se notifica cualquier otra restricción fuerte que no se cumpla.

Qué sucede en el caso donde en el Namespace haya Pods existentes creados con anterioridad, previo a configurar el control de admisión?

El comportamiento de los modos audit y warn será sin dudas similar, notificando al log de auditoría y al usuario cuando las políticas no puedan ser validadas con éxito. Acá se pueden visualizar los mensajes de warning correspondientes:

Warning: existing pods in namespace “my-namespace” violate the new PodSecurity enforce level “restricted:latest”Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfilenamespace/my-namespace configured

Por otro lado, el modo enforce, no podrá eliminar Pods que ya hayan sido creados.

Qué otra opción tenemos para controlar políticas de seguridad en el cluster a nivel Pods?

Si no existiese la limitación de usar herramientas nativas a Kubernetes, se podría elegir entre un abanico de posibilidades que ofrece la comunidad y permiten reemplazar, o bien complementar los niveles de seguridad vistos recientemente.

Éstas herramientas, denominadas Policy-as-code (PaC), proveen recursos extras para guiar a usuarios al uso correcto del cluster, así como a prevenir comportamientos inadecuados.