Admisión de seguridad Pod

La admisión de seguridad de pods implementa las normas de seguridad de pods de Kubernetes que restringen el comportamiento de los pods, proporcionando mensajes de advertencia y eventos de auditoría de kube-apiserver para los pods que violan la política de perfil de seguridad de pod configurada para el espacio de nombres relevante.

Red Hat OpenShift on IBM Cloud la versión 4.11 y posteriores incluyen soporte para la admisión de seguridad del pod Kubernetes. Para más información, consulte Admisión de seguridad de pods y Normas de seguridad de pods en la documentación de Kubernetes.

Pod Security Admission está siempre activado para Red Hat OpenShift on IBM Cloud versión 4.11 y posteriores. Las versiones anteriores de Kubernetes utilizan políticas de seguridad de vainas.

Conocer los perfiles de seguridad

Las normas de seguridad del pod Kubernetes definen los tres perfiles siguientes.

Privilegiado
La configuración de seguridad del pod por defecto aplica globalmente el perfil de seguridad del pod privileged Kubernetes, que no tiene restricciones y permite escaladas de privilegios conocidas, y genera advertencias y eventos de auditoría basados en las políticas establecidas por el perfil restricted.
Línea base
El perfil baseline es un perfil restrictivo que impide las escaladas de privilegios conocidas. Permite la configuración por defecto (mínimamente especificada) del Pod.
Restringida
El perfil restricted está fuertemente restringido y sigue las mejores prácticas actuales de endurecimiento de vainas.

Para obtener más información sobre los perfiles de seguridad de los pods, consulte Detalles del perfil en la documentación de Kubernetes.

Pod Security Admission contiene tres modos que definen qué acción emprende el plano de control si se detecta una posible infracción.

imponer
Las infracciones de la política hacen que se rechace la vaina.
auditoría
Las infracciones de la política provocan la adición de una anotación de auditoría al evento registrado en el registro de auditoría, pero por lo demás están permitidas.
warn
Las infracciones de la política provocan una advertencia al usuario, pero por lo demás están permitidas.

A medida que cambian las normas de seguridad o las implementaciones de perfiles para abordar nuevas funciones, puede configurar Pod Security Admission para que utilice una versión específica de las funciones. Se admiten las siguientes versiones.

  • Una versión de Kubernetes major.minor (por ejemplo, v1.25)
  • latest

¿Y si la Admisión de Seguridad en el Pod no es la opción adecuada para mí?

Aunque Pod Security Admission siempre está activado, puede ser uno de los múltiples controladores de admisión. Puede configurar controladores de admisión Kubernetes de terceros para implementar otros modelos de políticas de seguridad que se adapten a su caso de uso.

Si configura Pod Security Admission para aplicar, advertir y auditar mediante el perfil privileged, el plano de control permite que se ejecuten todos los pods. A continuación, puede configurar otros controladores de admisión para que los rechacen.

Puede instalar un controlador de admisión de terceros siempre que no realice ninguna de las siguientes acciones.

  • No instala sus propias políticas de seguridad de vainas (PSP).
  • No depende de los PSP para hacer cumplir partes de la política.

Configuración de etiquetas de espacio de nombres de admisión de Pod Security

Puede definir el modo de control de admisión que desea utilizar para la seguridad del pod en cada espacio de nombres. Kubernetes define un conjunto de etiquetas que puede establecer para definir cuál de los perfiles predefinidos de Pod Security Standard desea utilizar para un espacio de nombres. La etiqueta seleccionada define la acción que realiza el plano de control si se detecta una posible infracción.

Por defecto, Red Hat OpenShift on IBM Cloud añade las etiquetas privileged Pod Security a los siguientes espacios de nombres. Estos espacios de nombres se etiquetan como enforce, audit, y warn utilizando el perfil privileged.

  • kube-system
  • ibm-system
  • ibm-operators
  • calico-system
  • tigera-operator
  • calico-apiserver (Versión 4.16 y posteriores)

No elimine ni cambie las etiquetas de estos espacios de nombres ni de ninguno de los espacios de nombres de openshift-*.

Se puede etiquetar un espacio de nombres para establecer el perfil de seguridad del pod para cualquiera o todos los Pod Security Admission modes.

Por ejemplo, puede etiquetar un espacio de nombres para aplicar el perfil privileged además de utilizar warn o audit mediante el perfil baseline.

Esta etiqueta permite a los administradores y desarrolladores de aplicaciones ejecutar aplicaciones en seco buscando sólo advertencias y registros de auditoría contra el perfil baseline sin rechazar pods. A continuación, puede realizar los cambios necesarios en sus cargas de trabajo antes de cambiar el modo de aplicación a baseline.

Las etiquetas del espacio de nombres Pod Security Admission tienen la forma pod-security.kubernetes.io/<MODE>: <LEVEL> y pod-security.kubernetes.io/<MODE>-version: <VERSION>.

  • pod-security.kubernetes.io/enforce
  • pod-security.kubernetes.io/enforce-version
  • pod-security.kubernetes.io/audit
  • pod-security.kubernetes.io/audit-version
  • pod-security.kubernetes.io/warn
  • pod-security.kubernetes.io/warn-version

Para etiquetar un espacio de nombres con el fin de aplicar el perfil privileged y generar advertencias y eventos de auditoría en caso de infracción del perfil baseline, utilice las siguientes etiquetas.

  • pod-security.kubernetes.io/enforce: privileged
  • pod-security.kubernetes.io/enforce-version: latest
  • pod-security.kubernetes.io/audit: baseline
  • pod-security.kubernetes.io/audit-version: latest
  • pod-security.kubernetes.io/warn: baseline
  • pod-security.kubernetes.io/warn-version: latest

Configuración predeterminada del complemento Pod Security Admission

Red Hat OpenShift on IBM Cloud utiliza por defecto la siguiente dirección PodSecurityConfiguration.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

Configuración de la admisión de seguridad de pods

Puede configurar el comportamiento de seguridad del pod a nivel de espacio de nombres con etiquetas de seguridad de pod predefinidas. Para obtener más información sobre la configuración, consulte Control de la sincronización de admisión de seguridad de pods en la documentación de Red Hat OpenShift. Tenga en cuenta que los pasos varían para cada versión de clúster, así que asegúrese de que está viendo los pasos para la versión correcta.

Para obtener más información sobre la configuración de los registros de apiserver para Red Hat OpenShift on IBM Cloud, consulte Kubernetes Registros de auditoría del servidor API.

La admisión de seguridad de pods ofrece la posibilidad de imponer, advertir y generar eventos de auditoría para los pods que infrinjan los perfiles de seguridad. En OpenShift 4.11, la configuración por defecto impone el perfil privilegiado, a la vez que genera advertencias y eventos de auditoría basados en el perfil restricted. Este comportamiento puede controlarse a nivel de espacio de nombres mediante el uso de etiquetas de seguridad de pod predefinidas en los espacios de nombres. Cuando se aplican los perfiles de seguridad Pod, es posible que aparezcan advertencias como las del ejemplo siguiente.

`Warning: would violate PodSecurity "restricted:latest": host namespaces (hostNetwork=true, hostPID=true), privileged (container "container-00" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "container-00" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "container-00" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "host" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "container-00" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "container-00" must not set runAsUser=0), seccompProfile (pod or container "container-00" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")`

En este ejemplo, el pod sigue creado y puede ejecutarse siempre que la cuenta de servicio esté autorizada a un perfil de SecurityContextConstraint. La advertencia indica que es necesario realizar cambios en el perfil securityContext del pod y del contenedor para que el pod se ejecute bajo el perfil de seguridad del pod especificado, como establecer la opción allowPrivilegeEscalation=false o que debe utilizarse un perfil de seguridad del pod que permita esas capacidades.

Red Hat OpenShift también incluye un controlador que aplica etiquetas de espacio de nombres en función de los permisos SCC de las cuentas de servicio de un espacio de nombres determinado. Se aplican tanto la admisión de seguridad de pods como los SCC. Puede utilizar principalmente SCC y utilizar el controlador de sincronización de admisión de seguridad del pod para ajustar la etiqueta de seguridad del pod en el espacio de nombres. O bien, puede utilizar principalmente perfiles de seguridad de pods con una vinculación de funciones de espacio de nombres que permita a todas las cuentas de servicio del espacio de nombres utilizar un SCC equivalente (o con más privilegios). No defina vinculaciones de funciones o vinculaciones de funciones de clúster que se apliquen globalmente, como todos los usuarios autorizados o todas las cuentas de servicio en todos los espacios de nombres, ya que estas vinculaciones pueden afectar a los componentes de Red Hat OpenShift que esperan ejecutarse bajo un SCC concreto.

Recursos adicionales