Descripción de los perfiles de seguridad

Los estándares de seguridad de pod de Kubernetes definen los tres perfiles siguientes.

Privilegiado

La configuración de seguridad de pod predeterminada aplica de forma global el perfil de seguridad de pod de privileged Kubernetes, que no está restringido y permite escalamientos de privilegios conocidos, y genera avisos y sucesos de auditoría basados en las políticas establecidas por el perfil de restricted.

Línea base

El perfil baseline es un perfil restrictivo que impide escalabilidades de privilegios conocidas. Permite la configuración de pod predeterminada (especificada mínimamente).

Restringida

El perfil restricted está muy restringido y sigue los métodos recomendados de protección de pod actuales.

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

La admisión de seguridad de pod contiene tres modalidades que definen qué acción realiza el plano de control si se detecta una infracción potencial.

imponer

Las infracciones de política hacen que se rechace el pod.

auditoría

Las infracciones de política desencadenan la adición de una anotación de auditoría al suceso registrado en el registro de auditoría, pero por lo demás están permitidas.

warn

Las infracciones de política desencadenan un aviso de cara al usuario, pero de lo contrario se permiten.

A medida que cambian los estándares de seguridad o las implementaciones de perfiles para abordar las nuevas características, puede configurar Pod Security Admission para utilizar una versión específica de los roles. Se admiten las siguientes versiones.

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

¿Qué pasa si Pod Security Admission no es la opción correcta para mí?

Aunque la admisión de seguridad de pod siempre está habilitada, puede ser uno de varios controladores de admisión. Puede configurar controladores de admisión de Kubernetes de terceros para implementar otros modelos de política de seguridad que se adapten a su caso de uso.

Si configura la admisión de seguridad de pod para aplicar, avisar y auditar utilizando el perfil de privileged, el plano de control permite que se ejecuten todos los pods. A continuación, puede configurar otros controladores de admisión para rechazarlos.

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

• No instala sus propias políticas de seguridad de pod (PSP).
• No se basa en PSP para imponer partes de la política.

Configuración de etiquetas de espacio de nombres de admisión de seguridad de pod

Puede definir la modalidad de control de admisión que desea utilizar para la seguridad de 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 que seleccione define qué acción realiza el plano de control si se detecta una posible infracción.

De forma predeterminada, Red Hat OpenShift on IBM Cloud añade las etiquetas de seguridad de pod de privileged a los siguientes espacios de nombres. Estos espacios de nombres se etiquetan en 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 de pod para cualquiera o para todos los modes de admisión de seguridad de pod.

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

Esta etiqueta permite a los administradores y desarrolladores de aplicaciones ejecutar en seco aplicaciones buscando sólo avisos y registros de auditoría en el perfil de baseline sin rechazar pods. A continuación, puede realizar los cambios necesarios en las cargas de trabajo antes de cambiar la modalidad de imposición a baseline.

Las etiquetas de espacio de nombres de admisión de seguridad de pod tienen el formato 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 para imponer el perfil privileged y generar avisos y sucesos de auditoría para infracciones del perfil baseline, utilice las etiquetas siguientes.

• 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 plugin de admisión de seguridad de pod

Red Hat OpenShift on IBM Cloud utiliza el siguiente PodSecurityConfiguration de forma predeterminada.

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 pod

Puede configurar el comportamiento de seguridad de 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 pod 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 cómo configurar registros de apiserver para Red Hat OpenShift on IBM Cloud, consulte Registros de auditoría del servidor de API deKubernetes.

La admisión de seguridad de pod proporciona la capacidad de imponer, avisar y generar sucesos de auditoría para los pods que violan los perfiles de seguridad. En OpenShift 4.11, la configuración predeterminada aplica el perfil privilegiado, a la vez que genera avisos y sucesos de auditoría basados en el perfil restricted. Este comportamiento se puede controlar a nivel de espacio de nombres mediante el uso de etiquetas de seguridad de pod predefinidas en espacios de nombres. Cuando se aplican los perfiles de seguridad de pod, es posible que vea avisos como el 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 se sigue creando y se puede ejecutar siempre que la cuenta de servicio esté autorizada para un perfil de SecurityContextConstraint. El aviso indica que los cambios en el perfil securityContext del pod y contenedor son necesarios para que el pod se ejecute bajo el perfil de seguridad de pod especificado, como por ejemplo establecer la opción allowPrivilegeEscalation=false o que se debe utilizar un perfil de seguridad de pod que permita estas prestaciones.

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

Recursos adicionales

• Descripción y gestión de la admisión de seguridad de pod.
• Admisión de seguridad de pod en Red Hat OpenShift 4.11.
• Los registros de auditoría del servidor de API deKubernetes describen cómo configurar los registros de auditoría del servidor de API en el servicio Red Hat OpenShift on IBM Cloud.