En este tema se explica cómo configurar los controladores de admisión de seguridad de pods (Pod Security Admission, PSA) para proteger los clústeres de carga de trabajo implementados por Tanzu Kubernetes Grid (TKG).
Para los clústeres o los espacios de nombres dentro de los clústeres que ejecutan Kubernetes v1.23 y versiones posteriores, TKG admite la aplicación de directivas de seguridad de pods de tipo privileged
, baseline
o restricted
a través del controlador de admisión de seguridad de pods (Pod Security Admission, PSA).
Los controladores de PSA en Kubernetes le permiten configurar directivas de seguridad de carga de trabajo en dos ejes:
privileged
, baseline
y restricted
, de menos a más restrictivo.warn
genera una advertencia, audit
agrega una entrada de registro de auditoría y enforce
bloquea la creación del pod.Puede configurar controladores de PSA para que funcionen a través de espacios de nombres específicos o en todo el clúster. Por ejemplo, puede configurar un clúster para que active un registro de auditoría cuando un pod baseline
infrinja una directiva de seguridad y bloquee un pod de restricted
si infringe la directiva.
Para obtener más información, consulte Estándares de seguridad de pods en la documentación de Kubernetes.
El sistema PSA reemplaza las directivas de seguridad de pods (Pod Security Policies, PSP), que quedaron obsoletas en Kubernetes v1.21 y se eliminaron en la versión 1.25, como se describe en las notas de la versión de Kubernetes v1.25.
Las PSP para los nodos estaban obsoletas en TKG v2.1, para reflejar su desuso en Kubernetes. Para obtener información sobre cómo migrar pods de PSP al controlador PSA, consulte Migrar de PodSecurityPolicy al controlador de admisión de PodSecurity integrado.
La configuración de PSA predeterminada para clústeres de carga de trabajo de TKG depende de la versión de Kubernetes que se ejecuta:
warn
y audit
: restricted
enforce
: sin ajustewarn
y audit
: baseline
enforce
: sin ajusteLa configuración predeterminada de PSA para los clústeres que ejecutan las versiones nativas de Kubernetes en TKG 2.4, 2.3, 2.2 y 2.1 garantizan que los pods sigan ejecutándose durante la migración de PSP a PSA, incluso si generan advertencias sobre la infracción de la directiva:
A partir de TKG v2.2, todos los componentes internos de TKG cumplen con el perfil PSA restricted
.
Puede configurar un nuevo clúster con PSA en todo el clúster o cambiar el PSA de un clúster existente.
Para configurar un PSA de todo el clúster para un nuevo clúster de carga de trabajo, establezca POD_SECURITY_STANDARD_DEACTIVATED
en su archivo de configuración del clúster como false
y establezca las otras variables POD_SECURITY_STANDARD_*
como se describe en la tabla Estándares de seguridad de pods de la Referencia de variables del archivo de configuración.
POD_SECURITY_STANDARD_DEACTIVATED
POD_SECURITY_STANDARD_AUDIT
POD_SECURITY_STANDARD_WARN
POD_SECURITY_STANDARD_ENFORCE
También puede generar el manifiesto del clúster como el paso 1 del proceso de dos pasos descrito en Crear un clúster basado en clases y, a continuación, editar los valores de la variable podSecurityStandard
en la especificación Cluster
como en Cambiar PSA para un clúster basado en clases existente a continuación antes de crear el clúster en el paso 2.
Para cambiar la configuración de PSA de un clúster basado en clases existente:
Abra la especificación de objeto Cluster
en un editor:
kubectl edit -namespace NAMESPACE CLUSTER
Edite los valores en el bloque podSecurityStandard
en spec.topology.variables
:
- name: podSecurityStandard
value:
deactivated: DEACTIVATED
audit: AUDIT-PROFILE
enforce: ENFORCE-PROFILE
warn: WARN-PROFILE
auditVersion: AUDIT-VERSION
enforceVersion: ENFORCE-VERSION
warnVersion: WARN-VERSION
exemptions:
namespaces: [EXEMPT-NS]
Donde:
DEACTIVATED
es false
para aplicar un PSA en todo el clúster y true
de lo contrarioAUDIT-PROFILE
, ENFORCE-PROFILE
y WARN-PROFILE
son los perfiles de PSA para cada modo, que pueden ser "privileged"
, "baseline"
o "restricted"
. El valor predeterminado es "privileged"
.VERSION
son la versión de Kubernetes para los tres modos, por ejemplo, "v1.26"
.EXEMPT-NS
es una lista de espacios de nombres separados por comas que se excluyen del control de PSA.Nota: Los espacios de nombres del sistema
kube-system
ytkg-system
siempre se excluirán del control de PSA.
Cluster
, los cambios deben implementarse en los nodos del plano de control del clúster.Para cambiar la configuración de PSA de un clúster heredado existente:
Recupere el archivo de especificación actual AdmissionConfiguraton
del objeto KubeadmControlPlane
y guárdelo de forma local, por ejemplo:
kubectl get kcp my-cluster-control-plane --template='{{ range $v := .spec.kubeadmConfigSpec.files }}{{ if eq $v.path "/etc/kubernetes/admission-control-config.yaml" }}{{ $v.content }}{{ end }}{{ end }}' > admission-config.yaml
Edite el archivo admission-config.yaml
a la nueva configuración. Por ejemplo, el siguiente establece enforce
en baseline
y mantiene los modos audit
y warn
en restricted
:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1beta1
kind: PodSecurityConfiguration
defaults:
enforce: "baseline"
enforce-version: "v1.24"
audit: "restricted"
audit-version: "v1.24"
warn: "restricted"
warn-version: "v1.24"
exemptions:
usernames: []
runtimeClasses: []
namespaces: ["kube-system", "tkg-system"]
Edite la especificación del objeto KubeadmControlPlane
y reemplace su entrada de matriz en spec.kubeadmConfigSpec.files
por nuestro nuevo archivo de configuración.
Después de aplicar la especificación del objeto KubeadmControlPlane
, los cambios deben implementarse en los nodos del plano de control del clúster.
Antes de agregar o cambiar una PSA, evite el tiempo de inactividad inesperado asegurándose de que todas las cargas de trabajo existentes en el clúster o el espacio de nombres de PSA cumplan con la nueva configuración de directiva.
Puede evaluar si los pods que se ejecutan en un espacio de nombres existente cumplen con una directiva determinada ejecutando kubectl label --overwrite --dry-run=server
:
kubectl label --overwrite --dry-run=server namespace <namespace> pod-security.kubernetes.io/enforce=<policy>
La misma información se escribe en los registros de auditoría al configurar el modo audit
de admisión de seguridad de pods, o cuando se aplican recursos a un clúster y se configura el modo warn
.
Hay información actualizada disponible sobre los diferentes perfiles de seguridad de pods en la documentación de Kubernetes.