Skip to content

Pod Security Admission en Kubernetes

En este laboratorio, los alumnos aprenderán a configurar y utilizar Pod Security Admission en un clúster de Kubernetes. Pod Security Admission es una funcionalidad que permite aplicar políticas de seguridad a los pods, asegurando que cumplan con ciertos estándares de seguridad antes de ser creados o modificados.

Niveles de Seguridad en Pod Security Admission: Privileged, Baseline y Restricted

Pod Security Admission en Kubernetes proporciona tres niveles de seguridad predefinidos: privileged, baseline y restricted. Cada uno de estos niveles tiene diferentes restricciones y políticas de seguridad que se aplican a los pods para asegurar el cumplimiento de las mejores prácticas de seguridad. Aquí se explican las diferencias entre estos niveles:

Privileged:

El nivel privileged es el menos restrictivo de los tres niveles. Permite la ejecución de pods con configuraciones privilegiadas y menos seguras. Este nivel está diseñado para entornos donde se requiere un alto grado de flexibilidad y no se aplican restricciones de seguridad estrictas.

Características:

  • Permite el uso de todos los controles de seguridad contextuales.
  • Permite el uso de capacidades elevadas (capabilities).
  • Permite el uso de volúmenes privilegiados, como hostPath.
  • No impone restricciones en la escalación de privilegios (allowPrivilegeEscalation).

Uso: - Entornos de desarrollo y prueba donde la seguridad no es una preocupación principal. - Situaciones donde se requiere acceso total al host.

Baseline

El nivel baseline proporciona un equilibrio entre seguridad y funcionalidad. Aplica restricciones moderadas para mitigar riesgos comunes sin afectar significativamente la funcionalidad de los pods. Está diseñado para aplicaciones que necesitan algunas capacidades avanzadas pero aún requieren un cierto nivel de seguridad.

Características:

  • Permite ciertas capacidades elevadas, pero restringe las más peligrosas (NET_RAW).
  • Permite el uso de volúmenes no privilegiados.
  • Prohíbe la escalación de privilegios (allowPrivilegeEscalation debe estar deshabilitado).
  • Prohíbe el uso de hostPath y otros volúmenes privilegiados.
  • Requiere que los contenedores se ejecuten como no root (runAsNonRoot).

Uso:

  • Aplicaciones de producción que no requieren capacidades privilegiadas pero necesitan cierta flexibilidad.
  • Entornos donde se busca un equilibrio entre seguridad y funcionalidad.

Restricted

El nivel restricted es el más seguro de los tres niveles. Aplica las restricciones de seguridad más estrictas, limitando significativamente las capacidades del pod para mitigar riesgos de seguridad. Está diseñado para aplicaciones que necesitan el máximo nivel de seguridad.

Características: - Restringe todas las capacidades elevadas. - Prohíbe el uso de volúmenes privilegiados como hostPath. - Prohíbe la escalación de privilegios (allowPrivilegeEscalation debe estar deshabilitado). - Requiere que los contenedores se ejecuten como no root (runAsNonRoot). - Requiere la definición de un contexto de seguridad (seccompProfile, runAsUser, runAsGroup, etc.).

Uso: - Aplicaciones críticas para la seguridad donde la reducción de la superficie de ataque es primordial. - Entornos de producción que manejan datos sensibles o críticos y necesitan una configuración de seguridad estricta.

Rancher Kubernetes Engine unicamente soporta los niveles de seguridad: privileged y restricted

Guía Paso a Paso: Laboratorio de Pod Security Admission en Kubernetes

En este laboratorio, los alumnos aprenderán a configurar y utilizar Pod Security Admission en un clúster de Kubernetes. Pod Security Admission es una funcionalidad que permite aplicar políticas de seguridad a los pods, asegurando que cumplan con ciertos estándares de seguridad antes de ser creados o modificados.

Requisitos Previos

  • Un clúster de Kubernetes desplegado y funcionando.
  • kubectl configurado para interactuar con el clúster.
  • Acceso a la máquina desde donde se administrará el clúster.

Pasos

  1. Habilitar Pod Security Admission Realiza un respaldo del archivo de configuración del cluster: cluster.yml

    cp -p cluster.yml cluster.yml_bk_$(date +"%m_%d_%Y-%T")
    
    Editar el Archivo de Configuración del Cluster y agregar la línea pod_security_configuration: privileged:
    vi /home/student/devcluster/cluster.yml
    
    services:
      etcd:
        snapshot: true
      kube-api:
        pod_security_configuration: privileged
        service_cluster_ip_range: 10.43.0.0/16
    
    Guardar el archivo editado anteriormente

  2. Ejecura el comando rke up para reconfigurar el cluster

    rke up
    
    Espera a que finalice y deberias ver una salida como la siguiente:
    INFO[0046] Finished building Kubernetes cluster successfully
    

  3. Configurar Políticas de Seguridad de Pods, etiquetemos el namespace secure-ns con el nivel de seguridad restricted:
    kubectl create namespace secure-ns
    
    kubectl label namespace secure-ns pod-security.kubernetes.io/enforce=restricted
    
  4. Crear un Namespace sin Políticas de Seguridad: Creamos otro namespace unsecure-ns sin etiquetas de políticas de seguridad:
    kubectl create namespace unsecure-ns
    
  5. Crear un Pod Cumpliendo la Política Restricted: En el namespace secure-ns, creamos un pod que cumple con la política restricted:
    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: compliant-pod
      namespace: secure-ns
    spec:
      containers:
      - name: nginx
        image: nginx
        securityContext:
          runAsNonRoot: true
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          seccompProfile:
            type: RuntimeDefault
    EOF
    
  6. Crear un Pod Violando la Política Restricted: Intentamos crear un pod en secure-ns que viola la política restricted:
    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: non-compliant-pod
      namespace: secure-ns
    spec:
      containers:
      - name: nginx
        image: nginx
        securityContext:
          runAsUser: 0
          allowPrivilegeEscalation: true
    EOF
    
    Este pod debería ser rechazado por la política de seguridad restricted y mostrar un mensaje como el siguiente:
    Error from server (Forbidden): error when creating "STDIN": pods "non-compliant-pod" 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), runAsUser=0 (container "nginx" must not set runAsUser=0), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
    
  7. Creamos un pod similar al non-compliant-pod en el Namespace unsecure-ns, donde no hay políticas de seguridad aplicadas:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: non-compliant-pod
      namespace: unsecure-ns
    spec:
      containers:
      - name: nginx
        image: nginx
        securityContext:
          runAsUser: 0
          allowPrivilegeEscalation: true
    EOF
    
    Este pod debería ser creado exitosamente porque no hay restricciones aplicadas en unsecure-ns.

  8. Verificar los Pods en secure-ns:

    kubectl get pods -n secure-ns
    
    El pod compliant-pod debería estar en estado CreateContainerConfigError, ya que la imagen ha sido construida para ejecutarse como usuario root, lo cual no esta permitido Es posible verificarlo con el siguiente comando:
    kubectl get events -n secure-ns
    
    Se deberia de observar el siguiente mensaje:
    20m         Warning   Failed      pod/compliant-pod   Error: container has runAsNonRoot and image will run as root (pod: "compliant-pod_secure-ns(ab632c48-8542-4931-9f90-7df0aba8eba6)", container: nginx)
    
    El pod non-compliant-pod debería haber sido rechazado.

  9. Verificar los Pods en unsecure-ns:

    kubectl get pods -n unsecure-ns
    
    El pod non-compliant-pod debería estar en estado Running.

Limpieza del Ambiente

  1. Eliminar los Pods y Namespaces Creados:
    kubectl delete namespace secure-ns
    
    kubectl delete namespace unsecure-ns
    
  2. Restaurar la Configuración del API Server: Editar el Archivo de Configuración del Cluster:

    vi /home/student/devcluster/cluster.yml
    
    Y elimina la línea: pod_security_configuration: restricted
    services:
      etcd:
        snapshot: true
      kube-api:
        service_cluster_ip_range: 10.43.0.0/16
    
    Guardar el archivo editado anteriormente

  3. Ejecura el comando rke up para reconfigurar el cluster

    rke up
    
    Espera a que finalice y deberias ver una salida como la siguiente:
    INFO[0046] Finished building Kubernetes cluster successfully