Endurecer la cadena de suministro de software en Kubernetes y OpenShift
La mayoría de los compromisos modernos no entran por la aplicación: entran por el camino que lleva el código a producción. Este advisory resume seis controles concretos que aplicamos para que una imagen no llegue a correr sin estar firmada, escaneada y trazada.
Equipo de seguridad de ushiftDevSecOps · Supply chain · KubernetesSeis controles que cierran el camino a producción
Firmá y verificá las imágenes, y rechazá lo no firmado
Firmá cada imagen en el pipeline (por ejemplo con cosign) y exigí la verificación de la firma en el admission controller del clúster. Una política de admisión que solo deja correr imágenes firmadas por una clave conocida corta de raíz el despliegue de artefactos manipulados o de procedencia desconocida.
Escaneá vulnerabilidades con gating por severidad
Integrá un escáner (Trivy, Grype) en el build y bloqueá la promoción de imágenes con vulnerabilidades críticas o altas explotables. Las excepciones deben ser una allowlist explícita, acotada por CVE y con vencimiento, nunca un bypass general del control.
Eliminá las credenciales de larga vida del CI
Reemplazá las access keys estáticas por federación OIDC: que el runner obtenga credenciales efímeras asumiendo un rol, condicionado a la rama y al repositorio. Una llave filtrada en un log o en un fork deja de ser una puerta abierta a producción.
Aplicá políticas de admisión y un baseline de Pod Security
Usá un motor de políticas (Kyverno, OPA/Gatekeeper) y los Pod Security Standards para impedir contenedores privilegiados, montajes del host o imágenes de registries no aprobados. Empezá en modo auditoría para medir el impacto y pasá a enforce una vez saneadas las cargas.
Generá SBOM y procedencia para trazabilidad
Producí un SBOM por imagen y una atestación de procedencia del build. Cuando aparece un CVE nuevo en una dependencia, saber en minutos qué imágenes y qué servicios la incluyen es la diferencia entre una remediación dirigida y un apagón de incendios a ciegas.
Sacá los secretos del repo y rotalos
Ningún secreto en el código ni en el manifiesto. Inyectalos en tiempo de ejecución desde un gestor (External Secrets contra Vault/OpenBao o Secrets Manager), con permisos acotados por servicio y rotación periódica. Sumá escaneo de secretos en pre-commit para frenar filtraciones antes del push.
Ninguno de estos controles es exótico; lo difícil es sostenerlos todos, en cada release, sin frenar al equipo. Esa es la práctica que operamos en las plataformas que cuidamos, y la base sobre la que se construye un programa de cumplimiento que se verifica solo.