Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen KCSA. Lee de arriba a abajo o salta a una sección.
Diseñar una estrategia de seguridad nativa en la nube holística.
Implementar controles de seguridad a través de las 4 C: Cloud (fundación), Clúster, Contenedor y Código.
Por qué: Un compromiso en una capa exterior (por ejemplo, Cloud) socava la seguridad de todas las capas internas. La seguridad es tan fuerte como su eslabón más débil.
Protección contra fallos de seguridad de punto único.
Implementar múltiples controles de seguridad superpuestos en diferentes capas (por ejemplo, NetworkPolicies, RBAC, Security Contexts).
Por qué: Si un control falla o es eludido, otras capas continúan brindando protección, aumentando la dificultad para el atacante.
Asegurar el tráfico de red en un entorno donde la ubicación de la red no es un límite de confianza.
Implementar un modelo de "nunca confiar, siempre verificar". Autenticar y autorizar cada solicitud, típicamente usando una malla de servicios para mTLS.
Por qué: Asume que las amenazas pueden existir tanto dentro como fuera de la red, eliminando la confianza implícita basada en la posición de la red.
Limitar el radio de impacto de una identidad o componente comprometido.
Conceder a todos los sujetos (usuarios, cuentas de servicio, nodos) solo los permisos mínimos requeridos para realizar su función.
Por qué: Reduce el daño potencial que un atacante puede causar con credenciales robadas.
Reducir el costo y el impacto de las vulnerabilidades de seguridad.
Integrar el escaneo de seguridad automatizado (SAST, SCA, escaneo de imágenes) y las comprobaciones de políticas en las primeras etapas del pipeline de CI/CD.
Por qué: Encuentra y corrige vulnerabilidades antes en el ciclo de vida de desarrollo, cuando son más baratas de remediar.
Proteger los datos sensibles del clúster (especialmente Secrets) si el almacenamiento de etcd se ve comprometido.
En el kube-apiserver, usar `--encryption-provider-config` para habilitar el cifrado en reposo para los recursos antes de que se almacenen en etcd.
Por qué: Por defecto, los Secrets de Kubernetes solo están codificados en base64 en etcd. Esto proporciona un cifrado real en disco.
Prevenir el acceso no autorizado y la escucha de la comunicación de etcd.
Configurar etcd con mTLS tanto para la comunicación del cliente (`--client-cert-auth`) como para la del par (`--peer-client-cert-auth`).
Por qué: Garantiza que solo los componentes autenticados (apiserver, otros miembros de etcd) puedan comunicarse con etcd y que el tráfico esté cifrado.
Prevenir el acceso no autenticado al servidor API de Kubernetes.
Establecer el flag `--anonymous-auth=false`. Usar métodos de autenticación fuertes como OIDC o certificados x509.
Por qué: Deshabilita el usuario `system:anonymous`, forzando a que todas las solicitudes sean autenticadas y registradas contra una identidad específica.
Requisito para rastrear todos los cambios e intentos de acceso por seguridad y cumplimiento.
Habilitar el registro de auditoría del servidor API con `--audit-policy-file` y enviar los logs a un sistema de registro externo e inmutable.
Por qué: Proporciona una pista esencial e inalterable para la investigación de incidentes, la búsqueda de amenazas y las auditorías de cumplimiento.
Reducir la superficie de ataque de los nodos de trabajo.
Establecer los flags de kubelet: `--anonymous-auth=false`, `--authorization-mode=Webhook` y `--read-only-port=0`.
Por qué: Esto asegura que todas las solicitudes a la API de kubelet sean autenticadas y autorizadas por el servidor API y deshabilita el puerto de solo lectura inseguro y no autenticado.
Prevenir la fuga de información de los componentes del plano de control.
Establecer el flag `--profiling=false` en kube-apiserver, kube-controller-manager y kube-scheduler en producción.
Por qué: Los puntos finales de perfilado pueden exponer datos internos de rendimiento y detalles del sistema que podrían ayudar a un atacante en el reconocimiento.
Proteger los componentes del plano de control del acceso no autorizado a la red.
Usar reglas de firewall (grupos de seguridad en la nube, iptables) para restringir el acceso a los puertos del servidor API (6443) y etcd (2379) solo a fuentes de confianza.
Por qué: El control de acceso a nivel de red es una capa fundamental de defensa, impidiendo que los atacantes incluso alcancen las APIs de componentes sensibles.
Conceder permisos a usuarios o aplicaciones.
Usar `Roles` con ámbito de nombres en lugar de `ClusterRoles`. Conceder verbos específicos (`get`, `list`) en lugar de comodines (`*`).
Por qué: Sigue el principio del mínimo privilegio, limitando el alcance de los permisos a solo lo que es necesario dentro de un namespace específico.
Un pod no necesita comunicarse con la API de Kubernetes.
Establecer `automountServiceAccountToken: false` en la especificación del pod o en la propia ServiceAccount.
Por qué: Evita exponer credenciales innecesarias dentro del pod, reduciendo la superficie de ataque si el pod se ve comprometido.
Aplicar una postura de seguridad de referencia para todos los pods en un namespace.
Usar el controlador de admisión `PodSecurity` incorporado aplicando etiquetas de namespace como `pod-security.kubernetes.io/enforce: baseline`.
Por qué: Proporciona una forma estandarizada e incorporada de prevenir configuraciones de pods arriesgadas (como contenedores privilegiados) sin herramientas de terceros.
Reforzar la seguridad individual de los contenedores para prevenir la escalada de privilegios.
En la especificación del pod, establecer los campos de `securityContext`: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.
Por qué: Estos controles evitan ejecutar como root, bloquean mecanismos para obtener nuevos privilegios y hacen que el sistema de archivos del contenedor sea inmutable, reduciendo drásticamente el impacto de un compromiso.
Implementar un modelo de red de confianza cero dentro del clúster.
Aplicar una NetworkPolicy de denegación por defecto a cada namespace que seleccione todos los pods (`podSelector: {}`) y tenga una lista de reglas de entrada/salida vacía.
Por qué: La red de Kubernetes es de permiso por defecto. Esta política invierte el modelo a denegación por defecto, obligando a los desarrolladores a permitir explícitamente el tráfico requerido.
Permitir el tráfico solo entre capas de aplicación específicas (por ejemplo, de web a API).
Crear NetworkPolicies que utilicen `podSelector` y `namespaceSelector` para definir reglas de entrada y salida granulares basadas en etiquetas.
Por qué: Previene el movimiento lateral por parte de los atacantes asegurando que un pod comprometido solo pueda comunicarse con pares explícitamente autorizados.
Un usuario necesita permiso para ejecutar `kubectl exec` en contenedores para depuración.
Conceder el verbo `create` en el subrecurso `pods/exec` en el Role o ClusterRole relevante.
Por qué: La acción `exec` es controlada de forma poco intuitiva por el verbo `create` porque crea una nueva sesión de ejecución. Este es un punto de confusión común.
Un atacante obtiene acceso a un contenedor e intenta comprometer el nodo host.
Prohibir contenedores privilegiados (`securityContext.privileged: false`), namespaces del host (`hostNetwork`, `hostPID`) y el montaje del socket de Docker.
Por qué: Estas configuraciones rompen efectivamente el aislamiento del contenedor, otorgando a un contenedor comprometido acceso de nivel root al host.
Prevenir el despliegue de imágenes de contenedor con vulnerabilidades conocidas o código malicioso.
Implementar escaneo de imágenes (por ejemplo, Trivy) y verificación de firma de imágenes (por ejemplo, Cosign) en el pipeline de CI/CD y mediante control de admisión.
Por qué: Proporciona un enfoque de defensa en profundidad: el escaneo detecta vulnerabilidades conocidas, mientras que la firma verifica la integridad y procedencia de la imagen.
Un atacante ha comprometido un pod e intenta acceder a otros pods en el clúster.
Implementar NetworkPolicies de denegación por defecto y crear reglas de permiso específicas solo para la comunicación requerida de pod a pod.
Por qué: Restringe la "línea de visión" de un atacante desde un pod comprometido, conteniendo la brecha y evitando que se propague.
Prevenir que un pod comprometido robe credenciales de IAM de la nube del servicio de metadatos de la instancia.
Aplicar una NetworkPolicy de salida de denegación por defecto que bloquee explícitamente el tráfico a la IP de metadatos (por ejemplo, `169.254.169.254/32`).
Por qué: Esta es una ruta de ataque común en entornos de nube. Bloquear esta ruta de salida mitiga el riesgo de robo de credenciales de IAM de los pods.
Proteger contra ataques de denegación de servicio o cryptojacking que agotan los recursos del nodo.
Aplicar objetos `ResourceQuota` a los namespaces para limitar el uso total de recursos y objetos `LimitRange` para aplicar límites a pods individuales.
Por qué: Asegura que ningún inquilino o carga de trabajo individual pueda privar a otros de recursos, proporcionando estabilidad y previniendo el abuso.
Un atacante intenta mantener acceso a largo plazo a un clúster comprometido.
Monitorizar la creación de `DaemonSets`, `CronJobs` o pods privilegiados inesperados. Restringir los permisos para crear estos recursos.
Por qué: Los atacantes usan estos tipos de cargas de trabajo para asegurar que su código malicioso se ejecute persistentemente, incluso si un nodo o pod se reinicia.
Asegurar que las imágenes de contenedor estén libres de vulnerabilidades conocidas antes del despliegue.
Integrar un escáner de imágenes como Trivy, Clair o Grype en el pipeline de CI/CD para escanear imágenes y fallar la construcción si se encuentran vulnerabilidades críticas.
Por qué: Automatiza la detección de vulnerabilidades temprano ("shift left"), evitando que el código vulnerable llegue a producción.
Asegurar que solo se desplieguen imágenes de contenedor confiables y sin modificar en el clúster.
Firmar imágenes con una herramienta como Cosign en el pipeline de CI. Usar un controlador de admisión validador (por ejemplo, Kyverno, Gatekeeper) para verificar la firma en el momento del despliegue.
Por qué: Proporciona una prueba criptográfica de la integridad de la imagen (no ha sido alterada) y de su procedencia (proviene de una fuente confiable).
Detectar actividad maliciosa dentro de un contenedor en ejecución (por ejemplo, shell iniciado, acceso a archivos sensibles).
Desplegar una herramienta de seguridad en tiempo de ejecución como Falco, que utiliza eBPF para monitorizar llamadas al sistema y alertar sobre comportamientos sospechosos basándose en un conjunto de reglas definido.
Por qué: Proporciona visibilidad de la actividad en tiempo de ejecución, algo que el escaneo estático y el control de admisión no pueden ver. Es crucial para detectar brechas activas.
Aplicar políticas de seguridad personalizadas y específicas de la organización (por ejemplo, "todas las imágenes deben provenir de nuestro registro corporativo").
Usar un motor de políticas como OPA Gatekeeper o Kyverno como controlador de admisión validador para aplicar políticas escritas en Rego o YAML.
Por qué: Permite una aplicación flexible, declarativa y automatizada de políticas de seguridad que van más allá de los controles integrados de Kubernetes.
Cifrar y autenticar todo el tráfico de servicio a servicio dentro del clúster.
Implementar una malla de servicios (por ejemplo, Istio, Linkerd) para proporcionar automáticamente TLS mutuo (mTLS) para todos los servicios en la malla.
Por qué: Logra una red de confianza cero al asegurar que todo el tráfico dentro del clúster esté cifrado y que los servicios verifiquen mutuamente la identidad del otro.
Ejecutar cargas de trabajo no confiables o multiinquilino que requieren un aislamiento más fuerte que los contenedores estándar.
Usar un entorno de ejecución de contenedores en sandbox como gVisor o Kata Containers, que proporcionan una capa adicional de aislamiento entre el contenedor y el kernel del host.
Por qué: Reduce la superficie de ataque del kernel del host, haciendo que el escape del contenedor sea significativamente más difícil.
Control granular sobre los permisos de un contenedor a nivel del kernel.
Usar perfiles de Seccomp para filtrar las llamadas al sistema permitidas y perfiles de AppArmor/SELinux para aplicar controles de acceso obligatorios (MAC) en el acceso a archivos y redes.
Por qué: Estas características de seguridad nativas de Linux proporcionan una capa profunda de defensa, restringiendo lo que un proceso de contenedor comprometido puede hacer fundamentalmente.
Reducir la superficie de ataque dentro de una imagen de contenedor.
Construir imágenes de aplicación utilizando imágenes base mínimas o "distroless" que contengan solo la aplicación y sus dependencias directas.
Por qué: Elimina shells, gestores de paquetes y otras utilidades que son innecesarias para producción y podrían ser utilizadas por un atacante después de un compromiso.
Verificar que un clúster de Kubernetes está configurado de acuerdo con las mejores prácticas de seguridad.
Ejecutar regularmente `kube-bench`, una herramienta automatizada que verifica el clúster contra el CIS Kubernetes Benchmark.
Por qué: Proporciona una forma estandarizada, completa y automatizada de auditar la postura de seguridad del clúster e identificar configuraciones erróneas.
Un clúster debe procesar y almacenar datos de tarjetas de crédito en cumplimiento con PCI DSS.
Usar NetworkPolicies para la segmentación de red para aislar el Entorno de Datos del Titular de la Tarjeta (CDE), y habilitar el cifrado en reposo para etcd.
Por qué: Estos controles se mapean directamente a los requisitos de PCI DSS para la segmentación de red (Req 1) y la protección de los datos de los titulares de tarjetas almacenados (Req 3).
Un clúster maneja Información de Salud Protegida (PHI) y debe cumplir con HIPAA.
Implementar RBAC estricto, habilitar un registro de auditoría completo y asegurar que los datos estén cifrados tanto en reposo como en tránsito.
Por qué: Estos controles abordan las Salvaguardias Técnicas de HIPAA para el control de acceso, los controles de auditoría y la seguridad de la transmisión.
Asegurar que los registros de auditoría se conserven para cumplimiento y análisis forense, incluso si el clúster está comprometido.
Configurar el servidor API para transmitir registros de auditoría a un backend de registro externo, de solo escritura/inmutable (por ejemplo, un SIEM o un bucket de almacenamiento en la nube bloqueado).
Por qué: Evita que un atacante con privilegios de cluster-admin oculte sus huellas modificando o eliminando los registros de auditoría locales.