Seguridad en Kubernetes: Guía de Hardening para Producción

Kubernetes no tiene un botón de «activar seguridad». Es una disciplina en capas que abarca el plano de control, las cargas de trabajo, la red, la cadena de suministro y el runtime. Esta guía cubre los controles que más importan en producción, por qué existe cada uno y cómo implementarlos sin romper el clúster.

Para los equipos que operan en España o la Unión Europea, el hardening de Kubernetes no es solo una buena práctica técnica — es un requisito derivado del RGPD (Reglamento General de Protección de Datos) y, para entidades del sector público o proveedores de servicios esenciales, del ENS (Esquema Nacional de Seguridad). Las medidas descritas aquí son directamente aplicables a las categorías de control técnico que exigen ambos marcos.

La superficie de ataque en Kubernetes

Antes de aplicar ningún hardening, es imprescindible entender qué se está protegiendo. Un clúster de Kubernetes expone varias superficies de ataque diferenciadas:

• API server — El plano de control centralizado. Cualquier entidad que pueda alcanzarlo con credenciales válidas puede leer el estado del clúster, modificar cargas de trabajo o escalar privilegios.
• etcd — Almacena todo el estado del clúster en texto plano, incluidos los Secrets. El acceso directo a etcd equivale a tener root en todos los nodos.
• Nodos — Un nodo comprometido permite acceder a todos los Secrets montados en los pods que ejecuta, al API del kubelet, y potencialmente escapar al hipervisor subyacente.
• Pods — Los pods privilegiados, los que usan red del host o los que tienen capabilities excesivas pueden romper el aislamiento de contenedor.
• Cadena de suministro — Imágenes maliciosas, registros comprometidos y artefactos sin firmar pueden introducir código controlado por un atacante directamente en el clúster.
• RBAC — Los roles excesivamente permisivos permiten movimiento lateral y escalada de privilegios en cuanto un atacante consigue cualquier punto de apoyo inicial.

Los controles que se describen a continuación abordan cada una de estas superficies. Prioriza según tu modelo de amenazas: un clúster multi-tenant expuesto a internet los necesita todos; un clúster de desarrollo interno puede relajar algunos.

Una forma útil de pensar en la seguridad de Kubernetes es en términos de las cuatro fases del ciclo de vida del atacante: reconocimiento inicial, escalada de privilegios, movimiento lateral y exfiltración de datos. Cada sección de esta guía interfiere con una o más de esas fases. El hardening del API server y el RBAC dificultan la escalada inicial. Las network policies bloquean el movimiento lateral. El cifrado de Secrets y el control estricto de RBAC previenen la exfiltración. Falco y los audit logs permiten detectar y responder cuando las capas anteriores fallan.

1. RBAC: mínimo privilegio desde el primer día

El Control de Acceso Basado en Roles (RBAC) es el mecanismo principal de autorización de Kubernetes. La mayoría de los clústeres fallan en RBAC no porque esté mal configurado, sino porque es excesivamente permisivo por defecto y nadie lo revisa de forma sistemática.

Errores habituales en RBAC

• Asignar cluster-admin por comodidad. Prácticamente ninguna carga de trabajo necesita cluster-admin. Usa roles con scope de namespace siempre que sea posible.
• Usar * en verbos o recursos. Los permisos con wildcard son casi siempre más amplios de lo que se pretende.
• No auditar el uso de tokens de ServiceAccount. Cada pod tiene una ServiceAccount. La SA por defecto en la mayoría de los namespaces no tiene permisos, pero las cargas de trabajo personalizadas suelen recibir SAs excesivamente permisivas.
• Olvidar automountServiceAccountToken: false. Si una carga de trabajo no necesita comunicarse con el API de Kubernetes, deshabilita el montaje del token por completo.

Patrones RBAC prácticos

Para una carga de trabajo que solo necesita leer ConfigMaps en su propio namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: my-app
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-configmap-reader
  namespace: my-app
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: my-app
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

Audita el RBAC existente con kubectl-who-can o rbac-tool para localizar bindings excesivamente permisivos antes de que lo haga un atacante.

Nota RGPD/ENS: El principio de mínimo privilegio está recogido explícitamente en el artículo 25 del RGPD (privacidad por diseño) y en las medidas de control de acceso del ENS (categorías Media y Alta). Un RBAC correctamente dimensionado es evidencia directa de cumplimiento ante una auditoría.

2. Pod Security Standards: endurecimiento de cargas de trabajo

PodSecurityPolicy fue deprecada en Kubernetes 1.21 y eliminada en 1.25. Su reemplazo es Pod Security Admission (PSA), un admission controller integrado que aplica uno de tres perfiles de seguridad a nivel de namespace:

• Privileged — Sin restricciones. Solo para componentes del sistema.
• Baseline — Previene las escaladas de privilegios más críticas: contenedores privilegiados, hostPID, hostIPC, hostNetwork, capabilities peligrosas.
• Restricted — Aplica las mejores prácticas actuales de hardening. Requiere ejecutar como non-root, eliminar todas las capabilities y usar un perfil seccomp restringido.

Activa la aplicación a nivel de namespace con labels:

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

Un pod que ejecute como root o solicite host-network en un namespace con perfil restricted será rechazado en el momento de admisión. Los modos warn y audit permiten validar antes de aplicar la restricción.

PSA cubre las escaladas a nivel de pod más críticas, pero es de grano grueso. Para control de políticas más fino, combina Kyverno con PSA.

Una estrategia de adopción recomendada para clústeres existentes es empezar aplicando el nivel Baseline en modo warn en todos los namespaces de producción. Durante uno o dos sprints, el equipo revisa las advertencias y corrige las cargas de trabajo problemáticas — típicamente las que ejecutan como root por inercia histórica o las que montan el socket de Docker para tareas de CI. Una vez que las advertencias desaparecen, se pasa al modo enforce. Solo entonces se evalúa si algún namespace puede subir a Restricted. Este proceso gradual evita las interrupciones de producción que ocurren cuando se aplica Restricted directamente en un clúster heredado.

3. Network Policies: micro-segmentación del tráfico

Por defecto, cualquier pod de un clúster de Kubernetes puede comunicarse con cualquier otro pod en cualquier namespace. Este modelo de red plana otorga a un atacante movimiento lateral sin restricciones en cuanto compromete cualquier carga de trabajo.

Las Network Policies definen reglas de tipo allow en la capa L3/L4 para la comunicación pod-a-pod. Las aplica el plugin CNI (Calico, Cilium, Weave — Flannel no soporta NetworkPolicy).

Patrón de denegación por defecto

Empieza denegando todo el ingress y egress en cada namespace, y luego abre solo lo que sea explícitamente necesario:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: produccion
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Después permite el tráfico específico:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: produccion
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 5432

No olvides el egress de DNS — la mayoría de cargas de trabajo necesitan resolver nombres mediante kube-dns, lo que requiere egress UDP al puerto 53 hacia el namespace kube-system.

Si usas Cilium como CNI, puedes ir más allá de las Network Policies estándar de Kubernetes y aplicar políticas a nivel L7: restringir qué paths HTTP específicos puede llamar un pod, limitar la comunicación a determinados métodos gRPC, o filtrar por cabeceras HTTP. Cilium Network Policies son especialmente útiles en arquitecturas de microservicios donde diferentes servicios del mismo namespace deberían tener superficies de comunicación distintas.

La micro-segmentación de red es una de las medidas técnicas más efectivas para cumplir con el principio de «necesidad de saber» del RGPD y con los controles de segmentación de red del ENS. En una evaluación de cumplimiento, poder demostrar que la base de datos de producción solo es accesible desde los pods de la aplicación — y no desde cualquier pod del clúster — es evidencia tangible de control técnico implementado.

4. Gestión de Secrets

Los Secrets de Kubernetes están codificados en base64, no cifrados. Se almacenan en etcd en texto plano por defecto. Cualquier usuario con permiso get sobre Secrets puede leerlos. No es una vulnerabilidad — es una decisión de diseño que delega la responsabilidad en el operador:

• Activa el cifrado en reposo para etcd. Configura EncryptionConfiguration con un proveedor AES-CBC o AES-GCM. Esto cifra los Secrets antes de que se escriban en etcd.
• Usa almacenes externos de secretos. HashiCorp Vault, AWS Secrets Manager o Azure Key Vault con el External Secrets Operator hace que los valores reales de los secretos nunca residan en Kubernetes.
• Restringe el RBAC de Secrets de forma agresiva. Nunca otorgues list sobre Secrets a nivel de clúster — devuelve todos los valores. Usa get sobre recursos con nombre donde sea posible.
• Evita variables de entorno para secretos. Prefiere los volume mounts. Las variables de entorno son visibles en la salida de kubectl describe pod y pueden filtrarse a través del logging de la aplicación.

# Cifrado en reposo de etcd - en la configuración de kube-apiserver
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <clave-de-32-bytes-codificada-en-base64>
  - identity: {}

Contexto RGPD: El cifrado de datos en reposo es una medida técnica explícitamente recomendada por el artículo 32 del RGPD para proteger datos personales. Si los Secrets de tu clúster contienen credenciales de acceso a bases de datos con datos personales, el cifrado en reposo de etcd no es opcional desde la perspectiva del cumplimiento.

Un patrón cada vez más extendido en organizaciones que operan bajo el ENS o en sectores regulados (financiero, sanitario, administración pública) es adoptar el External Secrets Operator junto con HashiCorp Vault o Azure Key Vault. En este modelo, los Kubernetes Secrets actúan únicamente como proyección efímera de secretos que residen y se rotan en un sistema de gestión de secretos dedicado. El beneficio operativo es notable: rotación centralizada de credenciales sin redeployment de pods, auditoría completa de acceso a secretos, y una superficie de ataque mucho menor en caso de compromiso del clúster.

5. Seguridad de imágenes y cadena de suministro

La postura de seguridad en runtime es tan buena como las imágenes que ejecutas. Una imagen comprometida procedente de un registro público evade todos los controles de runtime que hayas implementado.

Escaneo de imágenes en CI/CD

Usa Trivy, Grype o Snyk para escanear imágenes como parte de tu pipeline de CI. Bloquea despliegues de imágenes con CVEs críticos:

# En el pipeline de CI
trivy image --exit-code 1 --severity CRITICAL tu-imagen:tag

Registro privado con control de admisión

Permite solo imágenes de tu registro privado usando un admission webhook (Kyverno, OPA Gatekeeper). Esto evita que los desarrolladores ejecuten imágenes públicas arbitrarias en producción:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-registries
    match:
      any:
      - resources:
          kinds: ["Pod"]
    validate:
      message: "Las imágenes deben proceder de registry.empresa.com"
      pattern:
        spec:
          containers:
          - image: "registry.empresa.com/*"

Imágenes distroless o de base mínima

Las imágenes distroless contienen solo la aplicación y sus dependencias de runtime — sin shell, sin gestor de paquetes, sin herramientas de diagnóstico. Esto reduce drásticamente la superficie de ataque y el número de CVEs. Las imágenes distroless de Google están disponibles para Java, Node.js, Python y Go.

Firma y verificación de imágenes

Cosign (del proyecto Sigstore) permite firmar imágenes de contenedor y verificar firmas en el momento de admisión mediante Kyverno o Connaisseur. Esto previene los ataques de sustitución de imágenes, en los que un atacante reemplaza una imagen legítima en el registro.

En entornos regulados europeos (banca, sanidad, administración pública), la firma de imágenes proporciona trazabilidad de la cadena de suministro de software, un requisito cada vez más presente en las auditorías ENS de categoría Alta y en los marcos de ciberseguridad del sector financiero (DORA).

SBOM: inventario de componentes de software

El Software Bill of Materials (SBOM) se está convirtiendo en un estándar de facto en la seguridad de cadenas de suministro. Herramientas como Syft permiten generar un SBOM en formato SPDX o CycloneDX a partir de cualquier imagen de contenedor. Combinado con Grype para el escaneo de vulnerabilidades contra el SBOM, obtienes trazabilidad completa de los componentes de tus imágenes sin necesidad de reconstruirlas. La directiva europea NIS2, transpuesta en España a través de la Ley de Coordinación y Gobernanza de la Ciberseguridad, incluirá progresivamente requisitos de gestión de riesgos en la cadena de suministro de software que hacen del SBOM una práctica recomendable para las organizaciones afectadas.

6. Seguridad en runtime

La seguridad en runtime detecta y responde a actividad maliciosa una vez que un contenedor ya está en ejecución. La herramienta principal en este ámbito es Falco — un proyecto CNCF que usa eBPF para monitorizar llamadas al sistema y generar alertas cuando los contenedores se comportan de forma inesperada.

Las reglas por defecto de Falco detectan patrones de ataque habituales:

• Shell lanzada dentro de un contenedor
• Conexión de red a una IP inesperada
• Escritura en rutas de fichero sensibles (/etc/passwd, /etc/shadow)
• Escalada de privilegios mediante binarios setuid
• Drift del contenedor (nuevos ficheros ejecutables escritos en runtime)

Combina Falco con perfiles seccomp para restringir las llamadas al sistema que puede realizar un contenedor a nivel del kernel. El perfil seccomp RuntimeDefault (disponible como perfil por defecto desde Kubernetes 1.27) bloquea más de 300 llamadas al sistema que los contenedores prácticamente nunca necesitan.

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      runAsUser: 65534
      capabilities:
        drop: ["ALL"]

Estas cuatro configuraciones de securityContext juntas (allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, runAsNonRoot: true, capabilities.drop: ALL) hacen que el escape de contenedor sea significativamente más difícil y satisfacen el estándar de seguridad de pods Restricted de Kubernetes.

Desde la perspectiva del ENS, el despliegue de herramientas de detección en tiempo de ejecución corresponde a los controles de monitorización continua (mp.si.4) en la categoría de medidas de protección de sistemas de información.

Un detalle importante sobre Falco: no es suficiente con desplegarlo; hay que gestionar las reglas activamente. Las reglas por defecto son un buen punto de partida, pero en un entorno productivo con muchos microservicios generarán falsos positivos que el equipo ignorará progresivamente — hasta que una alerta real quede enterrada en el ruido. La práctica correcta es ajustar las reglas por namespace o por etiqueta de deployment, silenciando los falsos positivos conocidos de cada servicio y manteniendo alertas nítidas para comportamientos realmente anómalos. Las alertas de Falco se pueden enrutar a sistemas de gestión de eventos de seguridad (SIEM) como OpenSearch Security Analytics, IBM QRadar o Microsoft Sentinel, que son comunes en organizaciones españolas de tamaño medio-grande.

7. Hardening del API Server

El API server es el componente más crítico a endurecer. Configuraciones clave:

• Deshabilita la autenticación anónima. --anonymous-auth=false garantiza que toda petición esté autenticada.
• Activa el audit logging. Registra todas las peticiones al API server en un fichero o mediante webhook. Sin audit logs no puedes investigar incidentes ni detectar abuso de RBAC.
• Restringe los plugins de admisión. Asegúrate de que NodeRestriction está activo — impide que los kubelets de los nodos modifiquen objetos fuera de su propio nodo.
• No expongas el API server a internet. Usa una VPN, un bastion host o un endpoint privado. Si necesitas exponerlo, restringe el acceso por IP.

# Política de auditoría mínima — registra todas las peticiones a nivel metadata,
# y el body completo para recursos sensibles
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: Metadata
  omitStages: ["RequestReceived"]

El audit logging del API server es equivalente a los registros de auditoría exigidos por el RGPD (artículo 30, registro de actividades de tratamiento) y por las medidas de trazabilidad del ENS. En una brecha de seguridad, estos logs son la diferencia entre poder demostrar qué ocurrió y no poder hacerlo.

La política de auditoría mínima mostrada arriba es un punto de partida. En producción, necesitarás ajustar los niveles según el volumen de peticiones y el coste de almacenamiento. Un error habitual es activar RequestResponse para todos los recursos — en un clúster activo puede generar cientos de gigabytes de logs al día. Una estrategia más sostenible es RequestResponse solo para recursos sensibles (secrets, configmaps, rolebindings) y Metadata para el resto. Los logs de auditoría deben exportarse a un sistema externo (Elasticsearch, S3, un SIEM) que el propio clúster no pueda modificar, para que sean útiles como evidencia forense.

8. Seguridad de etcd

etcd almacena todo el estado del clúster. Trátalo con la misma sensibilidad que tu base de datos de producción:

• Activa TLS para toda la comunicación de etcd. Tanto la comunicación entre pares (etcd-a-etcd) como la comunicación con clientes (apiserver-a-etcd) deben usar mutual TLS.
• Restringe el acceso de red a etcd. etcd solo debe ser alcanzable por el API server. Usa reglas de firewall o security groups para aplicarlo.
• Activa el cifrado en reposo. Como se describe en la sección de Secrets.
• Realiza backups de etcd de forma regular. Un snapshot de etcd es una copia completa de todo el estado del clúster, incluidos todos los Secrets. Cifra los backups y almacénalos de forma separada del clúster.

En entornos con certificación ENS, el backup y la restauración verificada de etcd forman parte de los controles de continuidad de operaciones. Los backups sin cifrar de etcd en un bucket de almacenamiento objeto son un vector de ataque frecuentemente ignorado.

9. CIS Kubernetes Benchmark

El CIS Kubernetes Benchmark es una lista de comprobación exhaustiva de controles de seguridad que abarca el plano de control, los nodos y las cargas de trabajo. Ejecutar kube-bench contra tu clúster te da una evaluación puntuada frente a los controles CIS:

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs $(kubectl get pods -l app=kube-bench -o name)

kube-bench genera PASS/FAIL/WARN para cada control con guías de remediación. Ejecútalo tras la configuración inicial del clúster y después de cambios de configuración significativos.

El CIS Kubernetes Benchmark tiene un mapeo documentado con los controles del ENS y con los requisitos técnicos de PCI-DSS. Si tu organización opera en el sector financiero español bajo supervisión del Banco de España o la CNMV, este benchmark es un punto de partida reconocido para demostrar diligencia técnica.

10. Postura de seguridad continua con Kubescape y Trivy Operator

Kubescape y herramientas similares (Trivy Operator, KubeScore) proporcionan escaneo continuo del estado real del clúster — no solo una auditoría puntual. Comprueban las cargas de trabajo frente a las guías de hardening NSA/CISA, el framework MITRE ATT&CK y el CIS Benchmark en tiempo real.

Despliega Trivy Operator para escaneo continuo en el clúster:

helm repo add aquasecurity https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aquasecurity/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.ignoreUnfixed=true"

Trivy Operator crea recursos personalizados VulnerabilityReport, ConfigAuditReport y RbacAssessmentReport en el mismo namespace que cada carga de trabajo. Estos pueden ser scrapeados por Prometheus y visualizados en Grafana para disponer de un dashboard de seguridad.

Esta capacidad de monitorización y reporte continuo resulta especialmente valiosa en entornos con obligaciones de revisión periódica: cumplimiento ENS, auditorías de seguridad ISO 27001, o revisiones de seguridad técnica previas a una certificación del CCN-CERT.

Lista de comprobación de hardening

• RBAC revisado — sin roles con wildcard, sin bindings innecesarios de cluster-admin
• Token automount de ServiceAccount deshabilitado para cargas de trabajo sin acceso al API
• Pod Security Standards aplicados a nivel de namespace (mínimo Baseline, Restricted donde sea posible)
• Network policies desplegadas — denegación por defecto con permisos explícitos
• Secrets cifrados en reposo en etcd
• Imágenes escaneadas en CI — sin CVEs críticos en producción
• Registro privado aplicado mediante control de admisión
• securityContext de contenedores endurecido (non-root, filesystem de solo lectura, sin capabilities)
• Perfil seccomp RuntimeDefault activado
• Audit logging del API server activado
• TLS de etcd y acceso de red restringido
• kube-bench ejecutado y hallazgos críticos/altos remediados
• Seguridad en runtime (Falco) desplegada y alertas enrutadas al equipo de guardia
• Escaneo continuo (Trivy Operator o Kubescape) desplegado

Preguntas frecuentes

¿Por dónde empiezo si mi clúster no tiene controles de seguridad hoy?

Empieza por los controles de mayor impacto y menor esfuerzo: audita tu RBAC (revoca cluster-admin donde no sea necesario), activa Pod Security Admission en modo warn en todos los namespaces, y despliega Trivy Operator. Estos tres pasos te dan visibilidad inmediata y previenen las escaladas de privilegio más comunes sin romper nada.

¿Activar Network Policies rompe la resolución DNS?

Sí, si despliegas una política de egress default-deny sin permitir explícitamente DNS. Añade una regla de egress que permita UDP puerto 53 al servicio kube-dns en kube-system cuando apliques network policies de denegación por defecto.

¿Está Kubernetes certificado para PCI-DSS, ENS o ISO 27001?

Kubernetes en sí no está certificado — tu configuración y los controles que implementas determinan el cumplimiento. El CIS Kubernetes Benchmark se mapea con muchos requisitos de PCI-DSS, ENS e ISO 27001. Las ofertas de Kubernetes gestionado (EKS, GKE, AKS) tienen sus propias certificaciones de cumplimiento para la infraestructura subyacente, pero la configuración del clúster y las cargas de trabajo siguen siendo responsabilidad del equipo.

En el contexto español, el CCN-CERT publica guías técnicas (series CCN-STIC) aplicables a la securización de plataformas de contenedores que complementan el ENS. Para entidades del sector público con sistemas de categoría Media o Alta, conviene consultar estas guías junto con el CIS Benchmark.

¿OPA Gatekeeper o Kyverno?

Ambas aplican políticas de admisión, pero Kyverno es nativo de Kubernetes (las políticas se escriben como YAML) mientras que Gatekeeper usa Rego (un lenguaje de políticas específico de dominio). Para equipos sin experiencia en Rego, Kyverno es significativamente más rápido de adoptar y mantener. Para equipos que ya usan OPA en otras partes de su stack, Gatekeeper ofrece consistencia. Ambos se integran bien con flujos de trabajo GitOps.

¿Con qué frecuencia debo actualizar Kubernetes para los parches de seguridad?

Aplica una release de parche en un plazo de 30 días desde su publicación para CVEs calificados como High o Critical. Las actualizaciones de versión minor (por ejemplo, 1.29 → 1.30) deben realizarse dentro de la ventana de soporte — Kubernetes mantiene las tres últimas versiones minor. Quedarse más de una versión minor por detrás significa ejecutar sin parches de seguridad para un subconjunto creciente de la base de código.

Kubernetes seguro en contexto DevSecOps

La seguridad de Kubernetes no es responsabilidad exclusiva del equipo de plataforma o de seguridad. En una organización que ha adoptado DevSecOps correctamente, los controles descritos en esta guía se integran en el ciclo de desarrollo normal:

• Los desarrolladores reciben feedback de seguridad en el pull request, antes de que el código llegue a producción. Herramientas como Trivy en CI, Checkov para Helm charts y Kubelinter para manifiestos YAML hacen posible esta detección temprana.
• Las políticas de Kyverno o Gatekeeper se gestionan como código (GitOps), con la misma revisión de código y proceso de aprobación que cualquier cambio de infraestructura.
• Los resultados de Trivy Operator y Kubescape se exponen en dashboards de Grafana accesibles para todo el equipo de ingeniería, no solo para el equipo de seguridad. La visibilidad compartida genera responsabilidad compartida.
• Las alertas de Falco se integran en el sistema de guardia (PagerDuty, OpsGenie) junto con las alertas de disponibilidad. La seguridad en runtime no puede tener un equipo de respuesta separado con tiempos de reacción más lentos que los incidentes de producción.

Este modelo — seguridad integrada en el flujo de trabajo, no añadida como capa posterior — es la diferencia entre un postura de seguridad que mejora continuamente y una que se deteriora con cada sprint.

Contenido relacionado

Para una visión más profunda de cómo la seguridad encaja en la arquitectura global de la plataforma Kubernetes, consulta la guía de patrones de arquitectura Kubernetes y la guía sobre construir una cultura de seguridad en Kubernetes.