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, IBM Cloud Kubernetes Service 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 (Versión 1.29 y posteriores)
• tigera-operator (Versión 1.29 y posteriores)
• calico-apiserver (Versión 1.31 )

No elimine ni cambie las etiquetas de estos espacios de nombres.

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

IBM Cloud Kubernetes Service 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: []

Personalización de la configuración del plug-in de Admisión de seguridad de pod

La configuración del plug-in de Admisión de seguridad de pod de todo el clúster establece el comportamiento enforce, audit y warn para todos los espacios de nombres que no tienen etiquetas de seguridad de pod o exenciones.

Para los clústeres de Kubernetes 1.24, apiVersion debe ser pod-security.admission.config.k8s.io/v1beta. Para 1.25 y posteriores pod-security.admission.config.k8s.io/v1 es preferible, pero se puede seguir utilizando la versión de la API de v1beta.

1. Cree un archivo YAML que contenga un recurso PodSecurityConfiguration. Puede utilizar la configuración predeterminada para iniciar.

   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: []
   

2. Realice las personalizaciones que desee utilizar. Revise la siguiente información sobre cada sección de la configuración.

   defaults

   La sección defaults de la configuración define los valores predeterminados de todo el clúster para los espacios de nombres que no tienen etiquetas de seguridad de pod. Los campos pueden tener los mismos valores que las etiquetas de espacio de nombres correspondientes.

   exemptions

   La sección exemptions de la configuración le permite crear pods que, de lo contrario, están prohibidos debido a la política asociada con un espacio de nombres específico. Las dimensiones de exención incluyen los casos siguientes.

   • Nombres de usuario: Las solicitudes de usuarios con un nombre de usuario autenticado (o suplantado) exento se ignoran. Los nombres de usuario suelen ser usuarios de IAM o cuentas de servicio. Por ejemplo, usernames: [ "IAM#user@example.com" ]. También puede eximir el nombre de usuario asociado a un certificado de cliente de admin kubeconfig. Si desea especificar un certificado de admin kubeconfig, el nombre de usuario es el componente CN del certificado de cliente actual.

     kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
     /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
     

     En el ejemplo siguiente, el nombre de usuario es IBMid-27000xxxxx-admin-2023-05-12. Si obtiene un nuevo admin kubeconfig, el nombre de usuario puede ser diferente.

     openssl x509 -in <client-certificate> -subject -noout`
     subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
     

   • RuntimeClassNames: Se ignoran los pods y recursos de carga de trabajo que especifiquen un nombre de clase en tiempo de ejecución exento.

   • Espacios de nombres: los pods y los recursos de carga de trabajo de un espacio de nombres exento se ignoran.

3. Guarde el archivo YAML de personalizaciones.

4. Ejecute el mandato ibmcloud ks cluster master pod-security set.

   ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE
   

Al ejecutar el mandato ibmcloud ks cluster master pod-security set, la admisión de seguridad de pod se restablece en la configuración predeterminada si no especifica un archivo de configuración.