Configuración de admisión de seguridad de pods

Etiquetas de admisión de seguridad de pod

Kubernetes define tres tipos de etiquetas para la admisión de seguridad de pods (consulte Tabla 2). Puede establecer estas etiquetas en un espacio de nombres para definir el nivel estándar de seguridad del pod que se utilizará. Sin embargo, no cambie el nivel estándar de seguridad pod en espacios de nombres del sistema como kube-system. De lo contrario, los pods en el espacio de nombres del sistema pueden estar defectuosos.

Los pods a menudo se crean indirectamente, mediante la creación de un objeto de carga de trabajo, como una Deployment o un trabajo. Para ayudar a detectar las infracciones con anticipación, tanto los modos de auditoría como de advertencia se aplican a los recursos de la carga de trabajo. Sin embargo, el modo de aplicación se aplica solo a los objetos pod resultantes.

Hacer cumplir la admisión de seguridad de pod con etiquetas de espacio de nombres

Puede etiquetar espacios de nombres para aplicar estándares de seguridad de pod. Suponga que un espacio de nombres está configurado de la siguiente manera:

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

    # The label can be in either of the following formats:
    # pod-security.kubernetes.io/<MODE>: <LEVEL> 
    # pod-security.kubernetes.io/<MODE>-version: <VERSION>  
    # The audit and warn modes inform you of which security behaviors are violated by the load.

Las etiquetas del espacio de nombres indican el nivel de política que se aplicará al modo. Para cada modo, hay dos etiquetas que determinan la política utilizada:

• pod-security.kubernetes.io/<MODE>: <LEVEL>
  • <MODE>: debe ser enforce, audit o warn. Para obtener más información sobre los modos, consulte Tabla 2.
  • <LEVEL>: debe ser privileged, baseline o restricted. Para obtener más información sobre los niveles, consulte Tabla 1.
• pod-security.kubernetes.io/<MODE>-version: <VERSION>

  Opcional, que ancla la política a una versión determinada de Kubernetes.

  • <MODE>: debe ser enforce, audit o warn. Para obtener más información sobre los modos, consulte Tabla 2.
  • <VERSION>: número de versión de Kubernetes. Por ejemplo, v1.25. También puede utilizar latest.

Si los pods se desplieguen en el espacio de nombres anterior, se aplican las siguientes restricciones de seguridad:

1. La verificación en el modo de aplicación se omite (modo de enforce + nivel de privileged).
2. Se verifican las restricciones relacionadas con la política de línea de base (modo de audit + nivel de baseline). Es decir, si el pod o contenedor infringen la política, el evento correspondiente se registra en el log de auditoría.
3. Se verifican las restricciones relacionadas con la política restringida (modo de warn + nivel restricted). Es decir, si el pod o contenedor infringen la política, el usuario recibirá una alarma al crear el pod.

Migración de la política de seguridad de pods a admisión de seguridad de pods

Si utiliza políticas de seguridad de pods en un clúster anterior a v1.25 y necesita reemplazarlas con admisión de seguridad de pods en un clúster de v1.25 o posterior, siga la guía de Migración de PodSecurityPolicy a la controladora de admisión integrada de PodSecurity.

1. La admisión de seguridad de pod admite solo tres modos de aislamiento, menos flexible que las políticas de seguridad de pod. Si necesita más control sobre restricciones específicas, necesitará usar un Validating Admission Webhook para aplicar esas políticas.
2. La admisión de seguridad de pod es un controlador de admisión que no cambia, lo que significa que no modificará los pods antes de validarlos. Si confiaba en este aspecto de PSP, necesitará modificar el contexto de seguridad en sus cargas de trabajo, o usar un Mutating Admission Webhook para realizar esos cambios.
3. PSP le permite vincular diferentes políticas a diferentes cuentas de servicio. Este enfoque tiene muchas trampas y no se recomienda, pero si requiere esta función de todos modos, tendrá que usar un webhook de terceros en su lugar.
4. No aplique la admisión de seguridad de pod a los espacios de nombres donde se despliegan los componentes de CCE, como kube-system, kube-public y kube-node-lease. De lo contrario, los componentes de CCE y las funciones adicionales serán anormales.

Documentación

• Admisión de seguridad de pod
• Asignación de PodSecurityPolicies a estándares de seguridad de pod
• Aplique estándares de seguridad de pods con etiquetas de espacio de nombres
• Aplique los estándares de seguridad de pod mediante la configuración del controlador de admisión integrado