Kubernetes: Lista de Comprobación Completa de Endurecimiento de la Seguridad

Lista de comprobación completa de endurecimiento de Kubernetes

La siguiente lista sigue el modelo de defensa en profundidad, organizado en seis dominios. Cada punto debe verificarse antes de promover un clúster a producción y revisarse periódicamente.

1. Plano de control y API Server

• Autenticación robusta: deshabilitar el acceso anónimo al API Server (--anonymous-auth=false); usar certificados X.509 o OIDC integrado con el proveedor de identidad corporativo.
• Autorización mínima: configurar el modo de autorización en RBAC; eliminar el modo AlwaysAllow y los roles cluster-admin concedidos a cuentas de servicio genéricas.
• Auditoría activada: habilitar el registro de auditoría del API Server con una política que capture al menos los eventos de nivel Metadata y Request para recursos sensibles.
• etcd cifrado en reposo: activar el cifrado a nivel de proveedor (EncryptionConfiguration) para los objetos Secrets almacenados en etcd; proteger el acceso a etcd con TLS mutuo.
• Admission Controllers: habilitar NodeRestriction, PodSecurity, DenyServiceExternalIPs y AlwaysPullImages; desactivar controladores no usados.
• Versión actualizada: mantenerse dentro de las dos versiones menores con soporte activo; aplicar parches de seguridad en un plazo máximo de 30 días desde su publicación.

2. Nodos y sistema operativo

• Usar imágenes de nodo mínimas (p. ej., Container-Optimized OS, Bottlerocket o Flatcar Linux) con superficie de sistema operativo reducida.
• Deshabilitar el acceso SSH directo a los nodos; utilizar bastion hosts con registro de sesión o soluciones de acceso privilegiado (PAM).
• Aplicar perfiles seccomp y AppArmor o SELinux en todos los nodos para restringir syscalls de los contenedores.
• Habilitar el auto-repair y el auto-upgrade de nodos en los servicios gestionados (GKE, EKS, AKS) o establecer un proceso equivalente para clústeres autoalojados.
• Aislar los nodos del plano de control en subredes privadas sin acceso directo desde Internet; usar grupos de seguridad o firewall rules para limitar el tráfico al API Server.

3. Cargas de trabajo y Pod Security Standards

• Pod Security Admission: aplicar el perfil Restricted en namespaces de producción y Baseline como mínimo en el resto; documentar excepciones justificadas con warn o audit antes de enforce.
• Prohibir contenedores con privileged: true, hostPID, hostNetwork o hostIPC salvo necesidad explícita documentada.
• Establecer readOnlyRootFilesystem: true, runAsNonRoot: true y definir runAsUser/runAsGroup distintos de 0 en el securityContext de cada contenedor.
• Configurar resources.requests y resources.limits en CPU y memoria para todos los contenedores; evitar pods sin límites que puedan agotar los recursos del nodo.
• Usar OPA/Gatekeeper o Kyverno para imponer políticas adicionales: registros de imágenes permitidos, etiquetas obligatorias, prohibición de imagen latest.

4. Red y segmentación

• Aplicar NetworkPolicies con política de denegación por defecto (default deny) en todos los namespaces y permitir solo el tráfico estrictamente necesario.
• Implementar mTLS entre microservicios mediante un service mesh como Istio o Cilium para cifrar el tráfico este-oeste dentro del clúster.
• Exponer servicios al exterior exclusivamente a través de un Ingress Controller con TLS terminado; nunca exponer puertos de base de datos o herramientas internas directamente mediante LoadBalancer o NodePort.
• Separar las cargas de trabajo por namespaces con límites de recursos (ResourceQuota, LimitRange) para evitar el movimiento lateral en caso de compromiso.

5. Gestión de identidades, RBAC y secretos

• Seguir el principio de mínimo privilegio en todos los Roles y ClusterRoles; auditar regularmente los permisos con herramientas como rbac-audit o kubectl-who-can.
• Deshabilitar el montaje automático del token de cuenta de servicio (automountServiceAccountToken: false) en pods que no necesiten acceso a la API.
• Gestionar secretos externos con HashiCorp Vault, AWS Secrets Manager o el External Secrets Operator; nunca almacenar credenciales en variables de entorno codificadas en manifiestos.
• Rotar certificados TLS y tokens de servicio según una política temporal definida; usar cert-manager para automatizar la renovación de certificados.
• Integrar el acceso al clúster con el proveedor de identidad corporativo (Azure AD, Okta, Google Workspace) mediante OIDC para aplicar MFA y gobierno centralizado de accesos.

6. Cadena de suministro de software y observabilidad

• Firmar todas las imágenes de contenedor con Cosign (proyecto Sigstore) y verificar la firma en el pipeline de admisión antes del despliegue.
• Escanear imágenes con Trivy o Grype en cada etapa del pipeline de CI/CD; bloquear el despliegue de imágenes con CVE de severidad crítica sin excepción documentada.
• Generar SBOM (Software Bill of Materials) para cada imagen y archivarlos como evidencia de cumplimiento, requisito creciente bajo NIS2.
• Centralizar los logs de auditoría del API Server, los eventos de Falco y los registros de aplicación en un SIEM (p. ej., Microsoft Sentinel, Elastic) con retención mínima de 12 meses para cumplir el ENS.
• Configurar Velero para realizar copias de seguridad periódicas del estado del clúster (recursos de Kubernetes y volúmenes persistentes) y probar la restauración al menos trimestralmente.
• Realizar ejercicios de penetration testing y revisiones de cumplimiento contra el CIS Kubernetes Benchmark con herramientas como kube-bench o Kubescape antes de cada cambio mayor de arquitectura.

Errores comunes que invalidan el endurecimiento

Incluso equipos experimentados caen en patrones que neutralizan el trabajo de configuración realizado. Los más frecuentes en entornos de producción españoles y europeos son:

• Excepciones permanentes sin revisión: namespaces en modo privileged que nacen como temporales y nunca se restringen. Cada excepción debe tener fecha de expiración y propietario asignado.
• Secretos en ConfigMaps o variables de entorno: un error de principiante que persiste en entornos maduros por inercia. Todo valor sensible debe pasar por un gestor de secretos dedicado.
• Network Policies incompletas: definir políticas de ingress pero olvidar las de egress permite que un pod comprometido exfiltre datos sin restricción.
• Imágenes con etiqueta latest: impide la trazabilidad de versiones y puede provocar que una imagen maliciosa o rota se despliegue en producción sin control.
• Auditoría desactivada por rendimiento: el argumento del overhead de I/O no justifica operar sin trazabilidad, especialmente bajo ENS nivel Alto o NIS2.
• RBAC heredado de la fase de desarrollo: permisos amplios concedidos durante las pruebas que nunca se revocan al pasar a producción.

Cumplimiento regulatorio europeo: RGPD, ENS y NIS2

El endurecimiento técnico de Kubernetes tiene correlación directa con los requisitos normativos vigentes en España y la UE:

La documentación de cada control implementado —versión de la herramienta, fecha de comprobación, resultado y responsable— es tan importante como el control mismo. Las autoridades supervisoras, como la Agencia Española de Protección de Datos (AEPD) o el CCN-CERT, pueden requerir evidencias en cualquier momento.

Cómo Opsio ayuda a endurecer clústeres de Kubernetes

Opsio es un proveedor de servicios gestionados en la nube con sede en Karlstad (Suecia) y centro de entrega en Bangalore (India), con reconocimientos como AWS Advanced Tier Services Partner, AWS Migration Competency, Microsoft Partner y Google Cloud Partner. Desde 2022, el equipo ha completado más de 3.000 proyectos y cuenta con más de 50 ingenieros certificados, incluyendo profesionales con certificaciones CKA (Certified Kubernetes Administrator) y CKAD (Certified Kubernetes Application Developer).

El servicio de endurecimiento de Kubernetes de Opsio abarca las siguientes capacidades diferenciadas:

• Evaluación inicial con kube-bench y Kubescape: auditoría automatizada contra el CIS Kubernetes Benchmark con informe de brechas priorizado por severidad y marco regulatorio aplicable (RGPD, ENS, NIS2).
• Implementación de controles mediante Terraform: toda la configuración de seguridad se codifica como infraestructura, garantizando reproducibilidad, trazabilidad en Git y reversibilidad controlada.
• Integración de detección en tiempo de ejecución: despliegue y ajuste de Falco con reglas adaptadas al perfil de amenaza del cliente, conectado a un SIEM existente o al stack de observabilidad de Opsio.
• Gestión de secretos con Vault o External Secrets Operator: migración desde variables de entorno o ConfigMaps a una solución de gestión de secretos con rotación automática.
• NOC 24/7 con SLA del 99,9 % de disponibilidad: monitorización continua de alertas de seguridad y respuesta ante incidentes, con escalado a ingenieros CKA certificados en cualquier franja horaria.
• Soporte al cumplimiento del ENS y RGPD: generación de evidencias documentales para auditorías, incluyendo registros de auditoría del API Server, reportes de escaneo de imágenes y registros de acceso privilegiado.

A diferencia de los enfoques puntuales de consultoría, Opsio opera como extensión permanente del equipo de ingeniería del cliente: el endurecimiento no es un proyecto con fecha de fin, sino un proceso continuo de revisión, actualización y validación que evoluciona junto con el clúster y el panorama de amenazas.

Más de nuestra base de conocimiento: Comprobación de sitios web vulnerables: Maximiza tus medidas de seguridad – Opsio

Más de nuestra base de conocimiento: Kubernetes Refuerzo de la seguridad: la lista de verificación completa para 2026