El deploy falla menos por Kubernetes y más por artefacto: imagen con tag mutable, build diferente por ambiente, dependencia sin rastro. Este capítulo trata de hacer el artefacto confiable y rastreable.

Regla que resuelve la mayor parte: construya una vez, promueva el mismo digest.

Sello del curso: probado con GitHub Actions, GHCR y Kubernetes 1.35.

Tag mutable es el problema

portal-backend:latest y hasta :v5 pueden apuntar a imágenes diferentes mañana. El pod en ejecución no es el pod que usted probó.

Use:

• sha-<commit> como tag principal.
• Digest (@sha256:...) en el deploy.
• Sin latest en producción.

docker build -t ghcr.io/example/portal-backend:sha-$GIT_SHA .
docker push ghcr.io/example/portal-backend:sha-$GIT_SHA
DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/example/portal-backend:sha-$GIT_SHA | cut -d@ -f2)
echo "$DIGEST"

En el manifest:

image: ghcr.io/example/portal-backend@sha256:2f0c...c91

Digest es inmutable por construcción.

Separe build de deploy

Etapa	Qué se ejecuta	Ambiente
build	test, lint, imagen, escaneo	runner
publish	push + SBOM + firma	runner
deploy homologación	actualiza digest en GitOps	ArgoCD
promueve prod	PR con el mismo digest	ArgoCD

El pipeline de prod no compila. Solo cambia el digest en el repositorio GitOps. Esto elimina "funcionó en homologación" por diferencia de build.

Pipeline mínimo

name: build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:sha-${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

El caché de build reduce minutos y, más importante, hace que el build sea reproducible.

Escaneo de vulnerabilidades

trivy image --severity HIGH,CRITICAL --exit-code 1 \
  ghcr.io/example/portal-backend:sha-$GIT_SHA

Estructura el gate:

• CRITICAL con corrección disponible: bloquea.
• CRITICAL sin corrección: registra y hace seguimiento.
• HIGH: alerta, no bloquea al principio.

Bloquear todo el primer día paraliza al equipo. El objetivo es reducir, no trabar.

SBOM

SBOM es la lista de componentes de la imagen. Sin ella, usted no responde "¿estamos afectados por Log4Shell?" en minutos.

syft ghcr.io/example/portal-backend:sha-$GIT_SHA -o spdx-json > sbom.spdx.json

Con Trivy:

trivy image --format spdx-json -o sbom.spdx.json ghcr.io/example/portal-backend:sha-$GIT_SHA

Publique el SBOM como artefacto del pipeline y haga referencia a él en el release. Formatos comunes: SPDX y CycloneDX.

Firma y procedencia

• cosign firma la imagen.
• SLSA provenance registra cómo fue construida.
• Admission controller (política de Kyverno/cosign) rechaza imagen no firmada.

cosign sign --yes ghcr.io/example/portal-backend@sha256:2f0c...c91
cosign verify ghcr.io/example/portal-backend@sha256:2f0c...c91 \
  --certificate-identity-regexp '.*' --certificate-oidc-issuer https://token.actions.githubusercontent.com

Esto cierra la cadena: commit → build → firma → deploy.

El error de seguridad que ya vimos

Un build pasó porque MinIO usaba minioadmin como credencial predeterminada. El pipeline no validaba la configuración — solo compilaba. Resultado: deploy roto en el clúster con INF-SEC-01.

Lección: el pipeline necesita un gate de configuración, no solo de test unitario:

grep -rE 'minioadmin|changeme|password.*=.*(admin|123)' deploy/ && exit 1

Simple, y habría evitado el incidente.

Trazabilidad: del pod al commit

Estandarice labels:

metadata:
  labels:
    app.kubernetes.io/name: portal-backend
    app.kubernetes.io/version: sha-3f9c1a
    org.opencontainers.image.revision: 3f9c1a...

Con esto:

kubectl -n portal get pod -l app.kubernetes.io/version=sha-3f9c1a

Usted responde "qué pod ejecuta el commit X" en segundos — y lo inverso también.

Laboratorio

1. Configure un pipeline que genera sha-<commit> y hace push.
2. Ejecute Trivy y vea el informe.
3. Genere el SBOM en SPDX e inspeccione dependencias.
4. Cambie el deploy para usar digest y confirme imageID en el pod:

kubectl -n portal get pod -o jsonpath='{.items[*].status.containerStatuses[*].imageID}'

5. Haga un commit que introduce una credencial falsa y vea fallar el gate.
6. Promueva el mismo digest de homologación a prod sin rebuild.

Errores comunes

Síntoma	Causa
Prod diferente de homologación	build separado por ambiente
ImagePullBackOff	credencial de registry o tag inexistente
Deploy “funcionó” y se rompió	tag mutable reutilizada
SBOM no generado	etapa falló silenciosamente
El escaneo bloquea todo	severidad sin política de excepción
Imagen sin firma aceptada	falta política de admisión
Trazabilidad perdida	imagen sin label de revisión

Checklist

• [ ] Build único por commit.
• [ ] Tag sha-<commit> y deploy por digest.
• [ ] Ningún latest en producción.
• [ ] Escaneo con severidad y política definidas.
• [ ] SBOM generado y archivado.
• [ ] Firma y verificación (cosign/Kyverno).
• [ ] Gate de configuración (credenciales predeterminadas).
• [ ] Labels de versión/revisión en los pods.
• [ ] Promoción por PR en el repo GitOps.

Glosario

• digest: hash inmutable de la imagen.
• SBOM: inventario de componentes.
• SLSA: framework de integridad de build.
• provenance: registro de cómo fue construido el artefacto.
• cosign: herramienta de firma.
• gate: etapa que bloquea el pipeline.

Próximo

Artefacto confiable y rastreable. Ahora a endurecer el clúster: RBAC, Pod Security Admission, NetworkPolicy y gestión de secretos.

Próximo: Curso Kubernetes 25 — Seguridad: RBAC, PSA, NetworkPolicy y secrets