Aplicar políticas de seguridad predefinidas a nivel de pod mediante PodSecurity

En esta página se explica cómo aplicar controles de seguridad predefinidos a nivel de pod en tus clústeres de Google Kubernetes Engine (GKE) mediante el PodSecurity controlador de admisión. Aplicar controles de seguridad a tus pods puede ayudarte a cumplir los requisitos de seguridad y cumplimiento. En esta página, obtendrá más información sobre PodSecurity y cómo aplicarlo a sus pods.

Esta página está dirigida a especialistas en seguridad que quieran aplicar controles de seguridad a sus clústeres de GKE. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Trusted Cloud by S3NS

Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:

Acerca de PodSecurity

PodSecurity es un controlador de admisión de Kubernetes que te permite aplicar estándares de seguridad de pods a los pods que se ejecutan en tus clústeres de GKE. Los estándares de seguridad de pods son políticas de seguridad predefinidas que cubren las necesidades de alto nivel de seguridad de los pods en Kubernetes. Estas políticas pueden ser muy permisivas o muy restrictivas.

Puedes aplicar los siguientes estándares de seguridad de pods a tus clústeres de GKE:

  • Privilegiada: una política sin restricciones que proporciona el nivel más amplio de permisos. Permite las apropiaciones de privilegios conocidas.
  • Configuración básica: una política mínimamente restrictiva que permite la configuración predeterminada y mínimamente especificada de los pods. Evita las apropiaciones de privilegios conocidas.
  • Restringido: una política muy restrictiva que sigue las prácticas recomendadas de protección de pods.

Puedes usar el controlador de admisión PodSecurity para aplicar los estándares de seguridad de pods en los siguientes modos:

  • Implementar: las infracciones de las políticas rechazan la creación de pods. Se añade un evento de auditoría al registro de auditoría.
  • Auditoría: las infracciones de las políticas activan la adición de un evento de auditoría al registro de auditoría. Se permite la creación de pódcasts.
  • Advertir: las infracciones de las políticas activan una advertencia visible para los usuarios. Se permite la creación de pods.

El controlador de admisión PodSecurity inserta estas políticas en la API de Kubernetes.

Si quieres crear y aplicar políticas de seguridad personalizadas a nivel de pod, te recomendamos que uses el controlador de admisión Gatekeeper.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Requisitos

El controlador de admisión PodSecurity está disponible y habilitado de forma predeterminada en los clústeres que ejecutan las siguientes versiones de GKE:

  • Versión 1.25 o posterior: estable
  • Versión 1.23 y versión 1.24: beta

Para comprobar si una versión de GKE está disponible y es la versión predeterminada de tu canal de lanzamiento, consulta la programación de lanzamientos.

Aplicar estándares de seguridad de pods mediante PodSecurity

Para usar el controlador de admisión PodSecurity, debes aplicar estándares de seguridad de pods específicos en modos específicos a espacios de nombres específicos. Para ello, puedes usar etiquetas de espacio de nombres. En este ejercicio, harás lo siguiente:

  • Crear dos espacios de nombres
  • Aplicar políticas de seguridad a cada espacio de nombres
  • Probar las políticas configuradas

En las siguientes versiones de GKE, GKE ignora las políticas que apliques al espacio de nombres kube-system:

  • 1.23.6-gke.1900 y versiones posteriores
  • 1.24.0-gke.1200 y versiones posteriores

En versiones anteriores de GKE, no apliques políticas en kube-system.

Crear espacios de nombres

Crea espacios de nombres en tu clúster:

kubectl create ns baseline-ns
kubectl create ns restricted-ns

Este comando crea los siguientes espacios de nombres:

  • baseline-ns: Para cargas de trabajo permisivas
  • restricted-ns: para cargas de trabajo muy restringidas

Usar etiquetas para aplicar políticas de seguridad

Aplica los siguientes estándares de seguridad de pods:

  • baseline: aplicar a baseline-ns en el modo warn
  • restricted: aplicar a restricted-ns en el modo enforce
kubectl label --overwrite ns baseline-ns pod-security.kubernetes.io/warn=baseline
kubectl label --overwrite ns restricted-ns pod-security.kubernetes.io/enforce=restricted

Estos comandos consiguen lo siguiente:

  • Se permiten las cargas de trabajo del espacio de nombres baseline-ns que infringen la política baseline y el cliente muestra un mensaje de advertencia.
  • Las cargas de trabajo del espacio de nombres restricted-ns que infrinjan la política restricted se rechazarán y GKE añadirá una entrada a los registros de auditoría.

Comprueba que se han añadido las etiquetas:

kubectl get ns --show-labels

El resultado debería ser similar al siguiente:

baseline-ns       Active   74s   kubernetes.io/metadata.name=baseline-ns,pod-security.kubernetes.io/warn=baseline
restricted-ns     Active   18s   kubernetes.io/metadata.name=restricted-ns,pod-security.kubernetes.io/enforce=restricted
default           Active   57m   kubernetes.io/metadata.name=default
kube-public       Active   57m   kubernetes.io/metadata.name=kube-public
kube-system       Active   57m   kubernetes.io/metadata.name=kube-system

Probar las políticas configuradas

Para comprobar que el controlador de admisión PodSecurity funciona correctamente, implementa una carga de trabajo que infrinja las políticas baseline y restricted en ambos espacios de nombres. El siguiente ejemplo de archivo de manifiesto implementa un contenedor nginx que permite la elevación de privilegios.

  1. Guarda el siguiente archivo de manifiesto como psa-workload.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true

  2. Aplica el manifiesto al espacio de nombres baseline-ns:

    kubectl apply -f psa-workload.yaml --namespace=baseline-ns

    El resultado debería ser similar al siguiente:

    Warning: would violate PodSecurity "baseline:latest": privileged (container "nginx" must not set securityContext.privileged=true)

    La política baseline permite que el pod se implemente en el espacio de nombres.

  3. Verifica que el pod se haya desplegado correctamente:

    kubectl get pods --namespace=baseline-ns -l=app=nginx

  4. Aplica el manifiesto al espacio de nombres restricted-ns:

    kubectl apply -f psa-workload.yaml --namespace=restricted-ns

    El resultado debería ser similar al siguiente:

    Error from server (Forbidden): error when creating "workload.yaml": pods "nginx"
is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation
!= false (container "nginx" must set securityContext.allowPrivilegeEscalation=false),
unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]),
runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true),
seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type
to "RuntimeDefault" or "Localhost")

    El pod no se desplegará en el espacio de nombres. Se añade una entrada de auditoría al registro.

Ver las infracciones de las políticas en los registros de auditoría

Las infracciones de las políticas en los modos audit y enforce se registran en los registros de auditoría de tu clúster. Puedes ver estos registros con el Explorador de registros de laTrusted Cloud consola.

  1. Ve a la página Explorador de registros de la consola de Trusted Cloud .

    Ir a Explorador de registros

  2. En el campo Consulta, especifica lo siguiente para obtener los registros de auditoría de los modos audit y enforce:

    resource.type="k8s_cluster"
protoPayload.resourceName:"/pods/nginx"
protoPayload.methodName="io.k8s.core.v1.pods.create"
(labels."pod-security.kubernetes.io/audit-violations":"PodSecurity" OR protoPayload.response.reason="Forbidden")

  3. Haz clic en Realizar una consulta.

  4. En la sección Resultados de la consulta, despliega la entrada de registro Forbidden para inspeccionar los registros de rechazo del modo enforce. Los detalles son similares a los siguientes:

    {
  ...
  protoPayload: {
    @type: "type.googleapis.com/google.cloud.audit.AuditLog"
    authenticationInfo: {1}
    authorizationInfo: [1]
    methodName: "io.k8s.core.v1.pods.create"
    request: {6}
    requestMetadata: {2}
    resourceName: "core/v1/namespaces/restricted-ns/pods/nginx"
    response: {
      @type: "core.k8s.io/v1.Status"
      apiVersion: "v1"
      code: 403
      details: {2}
      kind: "Status"
      message: "pods "nginx" is forbidden: violates PodSecurity "restricted:latest": privileged
              (container "nginx" must not set securityContext.privileged=true),
              allowPrivilegeEscalation != false (container "nginx" must set
              securityContext.allowPrivilegeEscalation=false), unrestricted capabilities
              (container "nginx" must set securityContext.capabilities.drop=["ALL"]),
              runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true),
              seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type
              to "RuntimeDefault" or "Localhost")"
      metadata: {0}
      reason: "Forbidden"
      status: "Failure"
      }
      serviceName: "k8s.io"
      status: {2}
    }
  receiveTimestamp: "2022-02-01T19:19:25.353235326Z"
  resource: {2}
  timestamp: "2022-02-01T19:19:21.469360Z"
}

  5. Despliega la entrada de registro audit-violations para inspeccionar los registros del modo audit. Los detalles son similares a los siguientes:

    {
  ...
  labels: {
    ...
    pod-security.kubernetes.io/audit-violations: "would violate PodSecurity "baseline:latest": privileged
                                                (container "nginx" must not set securityContext.privileged=true)"
    pod-security.kubernetes.io/enforce-policy: "privileged:latest"
  }
  operation: {4}
  protoPayload: {10}
  receiveTimestamp: "2023-12-26T05:18:04.533631468Z"
  resource: {2}
  timestamp: "2023-12-26T05:17:36.102387Z"
}

Limpieza

Para evitar que se apliquen cargos en tu cuenta de Trusted Cloud by S3NS , elimina los espacios de nombres:

kubectl delete ns baseline-ns
kubectl delete ns restricted-ns

Alternativas a PodSecurity

Además de usar el PodSecurity controlador de admisión de Kubernetes integrado para aplicar los estándares de seguridad de los pods, también puedes usar Gatekeeper, un controlador de admisión basado en Open Policy Agent (OPA), para crear y aplicar controles de seguridad personalizados a nivel de pod.

Siguientes pasos