Kubernetes empresarial: guia de seguridad

Por que la seguridad en Kubernetes importa

Kubernetes se ha convertido en el estandar de facto para orquestacion de contenedores en entornos empresariales. Segun el reporte de Cloud Native Computing Foundation (CNCF) de 2025, mas del 96% de las organizaciones evaluran o usan Kubernetes en produccion. Sin embargo, esta adopcion masiva trae consigo un superficie de ataque significativamente ampliada.

Un cluster Kubernetes mal configurado puede exponer servicios criticos, datos sensibles y la infraestructura completa de la organizacion. Los atacantes pueden escalar privilegios desde un contenedor comprometido hasta el control plane completo, acceder a secrets, robar credenciales de servicios en la nube o ejecutar criptomining en los nodos.

En entornos empresariales donde Kubernetes orquesta microservicios criticos, bases de datos y pipelines de CI/CD, una brecha de seguridad puede tener impacto catastrofico. La seguridad en K8s no es opcional: es un requisito fundamental para cualquier despliegue en produccion.

Arquitectura de seguridad: las capas criticas

Para proteger un cluster Kubernetes efectivamente, es fundamental entender las capas de seguridad que componen la arquitectura. Cada capa representa un vector de ataque potencial que debe ser evaluado y protegido individualmente.

Control Plane (Master Node)

El control plane es el cerebro del cluster. Contiene el API Server, etcd, Controller Manager y Scheduler. Un atacante que comprometa el control plane tiene control total sobre el cluster: puede crear pods privilegiados, acceder a todos los secrets y modificar la configuracion de cualquier recurso.

En produccion, el control plane debe ejecutarse en nodos dedicados con acceso restringido,通信 cifrada (TLS en todas las conexiones), y autenticacion robusta. Los servicios managed como EKS, GKE o AKS gestionan gran parte de esta capa, pero la responsabilidad compartida implica que el usuario debe configurar correctamente las politicas de acceso.

etcd

etcd es el almacén de estado distribuido que contiene toda la configuracion del cluster, incluyendo secrets, configurmaps con datos sensibles, y el estado de todos los recursos. Si etcd es comprometido, el atacante obtiene acceso a todo.

Las mejores practicas incluyen: cifrado en reposo (encryption at rest), acceso exclusivo desde el API server, autenticacion con certificados TLS, y backup cifrado fuera del cluster. En Kubernetes 1.27+, el cifrado en reposo para secrets esta habilitado por defecto, pero debe verificarse su configuracion.

API Server

El API server es la puerta de entrada al cluster. Todas las interacciones pasan por el. Debe configurarse con:

• Autenticacion multiple: certificados TLS, OIDC, webhooks
• Autorizacion RBAC: principios de menor privilegio estrictos
• Admission controllers: PodSecurity, ResourceQuotas, LimitRanges
• Audit logging: registro completo de todas las operaciones

Kubelet

El kubelet se ejecuta en cada nodo y gestiona los contenedores. Un kubelet expuesto sin autenticacion permite ejecutar contenedores arbitrarios en el nodo, escalar privilegios y acceder a la red del host. La API del kubelet debe protegerse con autenticacion TLS y autorizacion RBAC.

Hardening del cluster

El hardening es el proceso de reforzar la configuracion por defecto de Kubernetes para reducir la superficie de ataque. Los cuatro pilares del hardening son RBAC, NetworkPolicies, PodSecurity y Secrets Management.

RBAC (Role-Based Access Control)

RBAC determina quien puede hacer que acciones sobre que recursos. La configuracion por defecto de Kubernetes otorga permisos amplios que en produccion deben ser reducidos drasticamente.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]

Este ejemplo define un rol limitado que solo permite gestionar deployments y leer configmaps en un namespace especifico. Evita el uso de cluster-admin o roles con "*" en los verbos.

NetworkPolicies

Por defecto, todos los pods en un cluster pueden comunicarse entre si sin restricciones. Las NetworkPolicies implementan segmentacion de red a nivel de pod, similar a un firewall de micro-segmentacion.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080
      protocol: TCP

La primera politica deniega todo el trafico de entrada por defecto. La segunda permite exclusivamente el trafico del frontend al API server en el puerto 8080. Este patron "deny-all, allow-by-default" es fundamental para la segmentacion efectiva.

PodSecurity

Las politicas de seguridad de pods controlan lo que un contenedor puede hacer. Desde Kubernetes 1.25, PodSecurityPolicy fue reemplazado por el plugin de admision PodSecurity que opera en tres niveles: privileged, baseline y restricted.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

El nivel restricted prohíbe contenedores privilegiados, hostPath volumes, y requiere que los contenedores ejecuten como usuarios no-root con todas las capacidades de Linux eliminadas.

Secrets Management

Los secrets de Kubernetes por defecto solo estan codificados en base64, no cifrados. Para entornos empresariales, se recomienda integrar un gestor externo como HashiCorp Vault, AWS Secrets Manager o Sealed Secrets con Bitnami.

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  encryptedData:
    username: AgBy3i4OJSWK+PiTySYZZA9rO4...
    password: AgCB1hFvX2lEPlN9...

Seguridad de imagenes de contenedores

Las imagenes de contenedores son la unidad basica de despliegue en Kubernetes. Una imagen comprometida o vulnerable se propaga automaticamente a todos los pods que la utilizan.

Escaneo de vulnerabilidades

Cada imagen debe ser escaneada antes de llegar a produccion. Herramientas como Trivy, Snyk Container o Grype detectan vulnerabilidades conocidas en el software incluido en la imagen.

# Escaneo con Trivy antes del despliegue
trivy image --severity HIGH,CRITICAL \
  --exit-code 1 \
  registry.securelab.cl/app-api:v2.4.1

Integrar el escaneo en el pipeline de CI/CD es fundamental. Una imagen que no pasa el escaneo de seguridad no debe llegar a produccion bajo ninguna circunstancia.

Imagenes firmadas y verificacion

Con Cosign (parte de Sigstore), es posible firmar imagenes digitalmente y verificar la autenticidad antes del despliegue. Esto previene ataques de tipo supply chain donde un atacante reemplaza imagenes en el registro.

Registros privados con politicas de acceso

Los registros de imagenes privados deben configurarse con autenticacion robusta, escaneo automatico de imagenes subidas, y politicas que impidan el despliegue de imagenes desde fuentes no verificadas.

Monitoreo y deteccion de amenazas

La seguridad en Kubernetes no termina con el hardening. El monitoreo continuo es esencial para detectar actividades sospechosas, vulnerabilidades emergentes y configuraciones que se desvian de las politicas de seguridad.

Falco: deteccion en runtime

Falco es un proyecto CNCF que monitorea el comportamiento de los contenedores en tiempo real usando eBPF. Detecta actividades como shell spawning en contenedores, acceso a archivos sensibles, conexiones de red inesperadas y modificaciones al sistema de archivos.

# Regla personalizada de Falco
- rule: Detect crypto mining
  desc: Detect cryptocurrency mining processes
  condition: >
    spawned_process and container and
    proc.name in (xmrig, minerd, cpuminer,
    cryptonight, stratum)
  output: >
    Crypto mining detected
    (user=%user.name container=%container.name
    image=%container.image.repository)
  priority: CRITICAL

Audit Logs

Kubernetes genera logs de auditoria de todas las operaciones en el API server. Estos logs deben ser exportados a un sistema centralizado (SIEM) y procesados con reglas que detecten patrones de ataque como escalation de privilegios, acceso a secrets fuera de horario o creacion de recursos anomalos.

Runtime Security con Tetragon

Tetragon, desarrollado por Cilium, ofrece monitoreo de seguridad a nivel de kernel con eBPF. Permite detectar y prevenir en tiempo real actividades maliciosas como ejecucion de binarios no autorizados, accesso a archivos sensibles y connections de red sospechosas.

Errores comunes en Kubernetes empresarial

En nuestra experiencia evaluando clusters empresariales, los errores mas frecuentes incluyen:

• Uso de cluster-admin: Dar permisos de administrador a aplicaciones o usuarios que no lo necesitan
• Sin NetworkPolicies: Todos los pods pueden comunicarse libremente entre namespaces
• Secrets en texto plano: Credenciales hardcodeadas en manifests o expuestas en repositorios Git
• Contenedores privilegiados: Ejecutar con privilegios root innecesarios
• Sin escaneo de imagenes: Desplegar imagenes sin verificar vulnerabilidades
• API server expuesto: Kubelet API y API server accesibles desde internet sin autenticacion
• Sin ResourceQuotas: Un solo namespace puede consumir todos los recursos del cluster
• Sin backup de etcd: Perdida total del estado del cluster ante un fallo

Checklist de seguridad para Kubernetes

Utiliza esta lista como punto de partida para evaluar la postura de seguridad de tu cluster:

1. Control Plane: TLS habilitado en todas las conexiones, etcd cifrado en reposo, acceso restringido a nodos del master
2. RBAC: Principio de menor privilegio, sin ClusterRoleBinding innecesarios, audit logging habilitado
3. Red: NetworkPolicies implementadas en todos los namespaces, ingress controlado, egress filtrado
4. Pods: SecurityContext configurado, sin contenedores privilegiados, readOnlyRootFilesystem donde sea posible
5. Secrets: Gestor externo (Vault/Sealed Secrets), sin secrets en repositorios Git, rotation periodico
6. Imagenes: Escaneo en CI/CD, imagenes firmadas, registros privados con autenticacion
7. Monitoreo: Falco/Tetragon en runtime, audit logs exportados a SIEM, alertas configuradas
8. Updates: Politica de actualizacion de nodos y componentes,-Kubernetes LTS o versiones soportadas
9. Backup: Backups automatizados de etcd y manifests, prueba de restauracion periodica
10. Incident Response: Plan especifico para incidentes en K8s, runbooks para escenarios comunes