Seguridad en Kubernetes: Prácticas para Proteger sus Contenedores

Kubernetes se ha convertido en el orquestador de contenedores estándar del mercado para empresas que ejecutan sistemas distribuidos complejos. Sin embargo, al ser un ecosistema robusto y flexible, su configuración predeterminada prioriza la facilidad de desarrollo en detrimento de la seguridad restrictiva.

Sin el debido hardening (endurecimiento), los atacantes pueden escalar privilegios desde un solo contenedor para comprometer todo el clúster. A continuación, destacamos prácticas esenciales para proteger su Kubernetes.

1. Implemente el Principio de Menor Privilegio con RBAC

El control de acceso basado en roles (RBAC - Role-Based Access Control) permite restringir qué acciones pueden realizar los usuarios y los pods en las API de Kubernetes.

Recomendaciones:

• Nunca use la cuenta predeterminada system:serviceaccount:default con privilegios de administrador.
• Cree ServiceAccounts dedicadas para cada aplicación y asocie solo los permisos necesarios (por ejemplo: solo lectura en el namespace correspondiente).

2. Restrinja el Acceso a Recursos de los Pods (Security Context)

Por defecto, los contenedores Docker pueden ejecutarse como usuario root. Si un contenedor con privilegios de root se ve comprometido debido a vulnerabilidades, el atacante obtiene acceso completo al nodo físico anfitrión.

Qué configurar en los manifiestos (YAML):

Configure el bloque securityContext de su Pod para impedir la ejecución privilegiada:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: mi-app
    image: mi-app:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

Nota: El uso de readOnlyRootFilesystem bloquea cualquier escritura en el disco local del contenedor, forzando el uso de directorios temporales (tmpfs) o volúmenes persistentes montados explícitamente para escritura, impidiendo la inyección de scripts maliciosos.

3. Aplique Network Policies (Aislamiento de Red)

Por defecto, la red interna de Kubernetes está abierta: cualquier Pod de cualquier Namespace puede comunicarse libremente con otros Pods del clúster.

Cómo proteger:

• Habilite políticas de red (NetworkPolicies) para que actúen como un firewall interno de capa 3/4.
• Aísle las bases de datos y los sistemas de colas, configurándolos para aceptar conexiones únicamente de pods etiquetados con la label específica del microservicio autorizado.

4. RBAC y NetworkPolicy en el namespace

La cuenta del pod no hereda permiso de cluster. Este rol solo lee pods en el namespace tienda:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tienda-api
  namespace: tienda
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: leer-pods
  namespace: tienda
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tienda-api-leer-pods
  namespace: tienda
subjects:
  - kind: ServiceAccount
    name: tienda-api
    namespace: tienda
roleRef:
  kind: Role
  name: leer-pods
  apiGroup: rbac.authorization.k8s.io

La red cierra la base. Solo el pod con app=tienda-api habla en el puerto 5432:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-solo-api
  namespace: tienda
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: tienda-api
      ports:
        - protocol: TCP
          port: 5432

kubectl apply -f rbac-tienda.yaml
kubectl apply -f netpol-postgres.yaml
kubectl auth can-i list pods --as=system:serviceaccount:tienda:tienda-api -n tienda
kubectl auth can-i delete pods --as=system:serviceaccount:tienda:tienda-api -n tienda

La primera respuesta es yes. La segunda es no. La NetworkPolicy solo filtra tráfico si el CNI del cluster implementa la API. Sin eso, el YAML aplica y la red sigue abierta.

Conclusión

Garantizar la seguridad de los clústeres de Kubernetes exige un enfoque por capas. Al aplicar el aislamiento de red, políticas RBAC estrictas y contextos de seguridad en los Pods, su organización elimina los principales puntos ciegos de las infraestructuras contenedorizadas en producción.