En Kubernetes, la seguridad es una preocupación clave, especialmente a medida que los contenedores y los microservicios crecen en complejidad. Una de las características esenciales de Kubernetes para la aplicación de políticas es Pod Security Admission (PSA), que reemplaza las obsoletas Pod Security Policies (PSP). PSA proporciona un enfoque más sencillo y flexible para aplicar políticas de seguridad, ayudando a los administradores a proteger los clústeres asegurándose de que solo se ejecuten pods compatibles.

Este artículo te guiará a través de PSA, los Estándares de Seguridad de Pods disponibles, cómo configurarlos y cómo aplicar políticas de seguridad a espacios de nombres específicos usando etiquetas.

¿Qué es Pod Security Admission (PSA)?

PSA es un controlador de admisión incorporado introducido en Kubernetes 1.23 para reemplazar las Políticas de Seguridad de Pods (PSP). Las PSP tenían una curva de aprendizaje pronunciada y podían volverse engorrosas al escalar políticas de seguridad en varios entornos. PSA simplifica este proceso aplicando los Estándares de Seguridad de Pods de Kubernetes basados en niveles de seguridad predefinidos sin necesidad de lógica personalizada para cada política.

Con PSA, los administradores de clústeres pueden restringir los permisos de los pods utilizando etiquetas que corresponden a Estándares de Seguridad de Pods específicos. PSA opera a nivel de espacio de nombres, permitiendo una mejor granularidad en el control de políticas de seguridad para diferentes cargas de trabajo.

Estándares de Seguridad de Pods

Kubernetes proporciona tres Estándares de Seguridad de Pods clave en el marco de PSA:

• Privilegiado: Sin restricciones; permite todas las características y es el modo menos restrictivo. No se recomienda para cargas de trabajo de producción, pero puede usarse en entornos controlados o para cargas de trabajo que requieren permisos elevados.
• Básico: Proporciona un buen equilibrio entre usabilidad y seguridad, restringiendo los aspectos más peligrosos de los privilegios de los pods mientras permite configuraciones comunes. Es adecuado para la mayoría de las aplicaciones que no necesitan permisos especiales.
• Restringido: El nivel más estricto de seguridad. Este nivel está destinado a cargas de trabajo que requieren el más alto nivel de aislamiento y control, como clústeres multi-tenant o cargas de trabajo expuestas a internet.
  

Cada estándar incluye reglas específicas para limitar los privilegios de los pods, como prohibir contenedores privilegiados, restringir el acceso a la red del host y prevenir cambios en ciertos contextos de seguridad.

Configuración de Pod Security Admission (PSA)

Para habilitar PSA, necesitas etiquetar tus espacios de nombres según el nivel de seguridad que deseas aplicar. El formato de la etiqueta es el siguiente:

kubectl label --overwrite ns  pod-security.kubernetes.io/enforce=<value>

Por ejemplo, para aplicar una política de seguridad restringida en el espacio de nombres producción, ejecutarías:

kubectl label --overwrite ns production pod-security.kubernetes.io/enforce=restricted

En este ejemplo, Kubernetes aplicará automáticamente las reglas asociadas con la política restringida a todos los pods desplegados en el espacio de nombres producción.

Modos Adicionales de PSA

PSA también proporciona modos adicionales para un mayor control:

• Auditar: Registra una violación de política pero permite que el pod se cree.
• Advertir: Emite una advertencia pero permite la creación del pod.
• Aplicar: Bloquea la creación del pod si viola la política.
  

Para configurar estos modos, utiliza las siguientes etiquetas:

kubectl label --overwrite ns      pod-security.kubernetes.io/enforce=baseline     pod-security.kubernetes.io/audit=restricted     pod-security.kubernetes.io/warn=baseline

Esta configuración aplica el estándar básico mientras emite advertencias y registra violaciones para las reglas de nivel restringido.

Ejemplo: Configuración de Seguridad de Pods en un Espacio de Nombres

Veamos un ejemplo de cómo configurar la seguridad básica para el espacio de nombres dev. Primero, necesitas aplicar las etiquetas de PSA:

kubectl create namespace dev
kubectl label --overwrite ns dev pod-security.kubernetes.io/enforce=baseline

Ahora, cualquier pod desplegado en el espacio de nombres dev será verificado contra el estándar de seguridad básico. Si un pod viola la política básica (por ejemplo, al intentar ejecutar un contenedor privilegiado), se bloqueará su inicio.

También puedes combinar los modos advertir y auditar para rastrear violaciones sin bloquear pods:

kubectl label --overwrite ns dev     pod-security.kubernetes.io/enforce=baseline     pod-security.kubernetes.io/warn=restricted     pod-security.kubernetes.io/audit=privileged

En este caso, PSA permitirá que los pods se ejecuten si cumplen con la política básica, pero emitirá advertencias por violaciones de nivel restringido y registrará cualquier violación de nivel privilegiado.

Aplicación de Políticas por Defecto

Una de las fortalezas de PSA es su simplicidad para aplicar políticas a nivel de espacio de nombres, pero los administradores podrían preguntarse si hay una forma de aplicar una política por defecto en nuevos espacios de nombres automáticamente. Hasta ahora, Kubernetes no proporciona de forma nativa una opción para aplicar políticas de PSA globalmente por defecto. Sin embargo, puedes usar webhooks de admisión o herramientas de automatización como OPA Gatekeeper o Kyverno para aplicar políticas por defecto para nuevos espacios de nombres.

Conclusión

Pod Security Admission (PSA) simplifica la aplicación de políticas en clústeres de Kubernetes, facilitando el cumplimiento de los estándares de seguridad en diferentes entornos. Al configurar los Estándares de Seguridad de Pods a nivel de espacio de nombres y usar etiquetas, los administradores pueden controlar el nivel de seguridad de las cargas de trabajo con facilidad. La flexibilidad de PSA permite una gestión eficiente de la seguridad sin la complejidad asociada con las antiguas Políticas de Seguridad de Pods (PSP).

Para más detalles sobre la configuración de PSA y los Estándares de Seguridad de Pods, consulta la documentación oficial de PSA de Kubernetes y la documentación de Estándares de Seguridad de Pods.

In Kubernetes, security is a key concern, especially as containers and microservices grow in complexity. One of the essential features of Kubernetes for policy enforcement is Pod Security Admission (PSA), which replaces the deprecated Pod Security Policies (PSP). PSA provides a more straightforward and flexible approach to enforce security policies, helping administrators safeguard clusters by ensuring that only compliant pods are allowed to run.

This article will guide you through PSA, the available Pod Security Standards, how to configure them, and how to apply security policies to specific namespaces using labels.

What is Pod Security Admission (PSA)?

PSA is a built-in admission controller introduced in Kubernetes 1.23 to replace Pod Security Policies (PSPs). PSPs had a steep learning curve and could become cumbersome when scaling security policies across various environments. PSA simplifies this process by applying Kubernetes Pod Security Standards based on predefined security levels without needing custom logic for each policy.

With PSA, cluster administrators can restrict the permissions of pods by using labels that correspond to specific Pod Security Standards. PSA operates at the namespace level, enabling better granularity in controlling security policies for different workloads.

Pod Security Standards

Kubernetes provides three key Pod Security Standards in the PSA framework:

• Privileged: No restrictions; permits all features and is the least restrictive mode. This is not recommended for production workloads but can be used in controlled environments or for workloads requiring elevated permissions.
• Baseline: Provides a good balance between usability and security, restricting the most dangerous aspects of pod privileges while allowing common configurations. It is suitable for most applications that don’t need special permissions.
• Restricted: The most stringent level of security. This level is intended for workloads that require the highest level of isolation and control, such as multi-tenant clusters or workloads exposed to the internet.
  

Each standard includes specific rules to limit pod privileges, such as disallowing privileged containers, restricting access to the host network, and preventing changes to certain security contexts.

Setting Up Pod Security Admission (PSA)

To enable PSA, you need to label your namespaces based on the security level you want to enforce. The label format is as follows:

kubectl label --overwrite ns  pod-security.kubernetes.io/enforce=<value>

For example, to enforce a restricted security policy on the production namespace, you would run:

kubectl label --overwrite ns production pod-security.kubernetes.io/enforce=restricted

In this example, Kubernetes will automatically apply the rules associated with the restricted policy to all pods deployed in the production namespace.

Additional PSA Modes

PSA also provides additional modes for greater control:

• Audit: Logs a policy violation but allows the pod to be created.
• Warn: Issues a warning but permits the pod creation.
• Enforce: Blocks pod creation if it violates the policy.
  

To configure these modes, use the following labels:

kubectl label --overwrite ns      pod-security.kubernetes.io/enforce=baseline     pod-security.kubernetes.io/audit=restricted     pod-security.kubernetes.io/warn=baseline

This setup enforces the baseline standard while issuing warnings and logging violations for restricted-level rules.

Example: Configuring Pod Security in a Namespace

Let’s walk through an example of configuring baseline security for the dev namespace. First, you need to apply the PSA labels:

kubectl create namespace dev
kubectl label --overwrite ns dev pod-security.kubernetes.io/enforce=baseline

Now, any pod deployed in the dev namespace will be checked against the baseline security standard. If a pod violates the baseline policy (for instance, by attempting to run a privileged container), it will be blocked from starting.

You can also combine warn and audit modes to track violations without blocking pods:

kubectl label --overwrite ns dev     pod-security.kubernetes.io/enforce=baseline     pod-security.kubernetes.io/warn=restricted     pod-security.kubernetes.io/audit=privileged

In this case, PSA will allow pods to run if they meet the baseline policy, but it will issue warnings for restricted-level violations and log any privileged-level violations.

Applying Policies by Default

One of the strengths of PSA is its simplicity in applying policies at the namespace level, but administrators might wonder if there’s a way to apply a default policy across new namespaces automatically. As of now, Kubernetes does not natively provide an option to apply PSA policies globally by default. However, you can use admission webhooks or automation tools such as OPA Gatekeeper or Kyverno to enforce default policies for new namespaces.

Conclusion

Pod Security Admission (PSA) simplifies policy enforcement in Kubernetes clusters, making it easier to ensure compliance with security standards across different environments. By configuring Pod Security Standards at the namespace level and using labels, administrators can control the security level of workloads with ease. The flexibility of PSA allows for efficient security management without the complexity associated with the older Pod Security Policies (PSPs).

For more details on configuring PSA and Pod Security Standards, check the official Kubernetes PSA documentation and Pod Security Standards documentation.