Tu pipeline CI/CD puede tener controles de seguridad herméticos —commits firmados, dependencias fijadas, escaneos SAST, firma de imágenes de contenedores— pero nada de eso importa si el proceso de despliegue en sí es débil. El despliegue es la unión crítica donde la seguridad del pipeline se encuentra con la seguridad en producción. Un workflow de despliegue comprometido puede eludir cada control upstream que hayas construido, empujando código malicioso directamente al entorno del que dependen tus clientes.
Esta guía cubre cómo construir workflows de despliegue seguros de extremo a extremo: elegir el modelo de despliegue adecuado, aplicar gates y aprobaciones, verificar artefactos en el momento del despliegue, implementar cambios de forma progresiva y mantener una pista de auditoría completa desde el commit hasta producción.
Modelos de Despliegue: Push-Based vs Pull-Based (GitOps)
La primera decisión arquitectónica que define tu postura de seguridad en el despliegue es si utilizas un modelo push-based o pull-based.
Despliegues Push-Based (Impulsados por CI)
En un modelo push-based tradicional, el pipeline CI/CD construye el artefacto y luego lo envía directamente al entorno de destino. GitHub Actions despliega en Kubernetes vía kubectl apply, o un job de GitLab CI ejecuta helm upgrade contra un clúster. El pipeline en sí posee las credenciales del entorno de producción.
Este modelo es directo pero conlleva un riesgo inherente: el runner de CI tiene acceso de escritura directo a producción. Si un atacante compromete el pipeline —a través de una dependencia envenenada, un pull request malicioso o un secreto robado— hereda ese acceso a producción de forma inmediata.
Despliegues Pull-Based (GitOps)
En un modelo pull-based o GitOps, un controlador dedicado que se ejecuta dentro del entorno de destino —como Flux o ArgoCD— observa un repositorio Git en busca de cambios en el estado deseado. Cuando se hace commit de un nuevo manifiesto (típicamente el pipeline CI actualizando un tag de imagen), el controlador extrae el cambio y reconcilia el clúster para que coincida.
La ventaja de seguridad es significativa. El pipeline CI nunca necesita credenciales directas al clúster de producción. La superficie de ataque se reduce porque el agente de despliegue vive dentro del clúster y solo extrae de una fuente conocida. La detección de drift está incorporada: si alguien modifica manualmente un recurso, el controlador lo revierte para que coincida con Git.
Recomendación: Para cargas de trabajo en producción, prefiere un modelo pull-based de GitOps. Reserva los despliegues push-based para entornos de desarrollo y staging donde la velocidad importa más que el control de acceso estricto. Incluso en configuraciones push-based, aplica el principio de mínimo privilegio rigurosamente a las credenciales de despliegue.
Gates de Despliegue: Aprobaciones Manuales y Entornos Protegidos
Los pipelines automatizados son rápidos, pero el despliegue a producción no debería ocurrir sin verificación humana para cambios de alto impacto. Los gates de despliegue introducen puntos de control que requieren aprobación explícita antes de que un release proceda.
GitHub Environments y Revisores Requeridos
GitHub Actions soporta Environments con reglas de protección. Puedes requerir que uno o más revisores aprueben un despliegue antes de que el job se ejecute. Esto se configura en los ajustes del repositorio y se aplica a nivel de plataforma —el código del pipeline no puede eludirlo.
# .github/workflows/deploy.yml
jobs:
deploy-production:
runs-on: ubuntu-latest
environment:
name: production
url: https://app.example.com
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Verify artifact signature
run: |
cosign verify \
--key cosign.pub \
ghcr.io/myorg/myapp:${{ github.sha }}
- name: Deploy to production
run: |
helm upgrade --install myapp ./chart \
--set image.tag=${{ github.sha }} \
--namespace production
Con el environment production configurado para requerir revisores, este job se pausará y esperará aprobación antes de ejecutar cualquier paso. El aprobador ve exactamente qué commit y ejecución de workflow desencadenó el despliegue.
GitLab Protected Environments
GitLab ofrece protected environments que restringen qué usuarios o grupos pueden desencadenar despliegues. Combinado con jobs manuales, esto crea un workflow de aprobación robusto.
# .gitlab-ci.yml
deploy_production:
stage: deploy
environment:
name: production
url: https://app.example.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
script:
- cosign verify --key cosign.pub $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- helm upgrade --install myapp ./chart
--set image.tag=$CI_COMMIT_SHA
--namespace production
resource_group: production
La directiva when: manual requiere que un usuario haga clic en «Play» en la interfaz de GitLab. El resource_group asegura que solo un despliegue se ejecute a la vez, previniendo condiciones de carrera.
Aprobaciones Basadas en Slack y ChatOps
Para equipos que viven en Slack, integrar workflows de aprobación con chat proporciona visibilidad y tiempos de respuesta rápidos. Herramientas como Opsgenie, PagerDuty o bots personalizados de Slack pueden publicar una solicitud de despliegue en un canal y esperar a que un usuario autorizado apruebe mediante un botón o una reacción. El requisito clave es que el mecanismo de aprobación sea auditable y no pueda ser falsificado —usa tokens verificados de la app de Slack y registra cada decisión de aprobación.
Verificación de Artefactos en el Momento del Despliegue
Firmar artefactos durante la fase de build es solo la mitad de la ecuación. Debes verificar esas firmas en el momento del despliegue. De lo contrario, un atacante que obtenga acceso a tu registry puede reemplazar una imagen firmada con una maliciosa sin firmar o re-firmada.
Verificación con Cosign Antes del Despliegue
Añade un paso de verificación explícito en tu pipeline de despliegue que se ejecute antes de cualquier comando de despliegue. Si la verificación falla, el pipeline debe detenerse de inmediato.
# Verificar la firma de la imagen antes de desplegar
cosign verify \
--certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/myorg/myapp@sha256:abc123...
# Verificar la procedencia SLSA
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/myorg/myapp@sha256:abc123...
Admission Controllers: Kyverno y Sigstore Policy Controller
La verificación a nivel de pipeline es buena, pero puede ser eludida si alguien despliega directamente al clúster usando kubectl. Los admission controllers aplican la verificación a nivel del API server de Kubernetes —ninguna imagen sin firmar puede entrar al clúster independientemente de cómo fue enviada.
Kyverno es un motor de políticas nativo de Kubernetes que puede verificar firmas de imágenes y attestations como parte de su admission webhook:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-signed-images
spec:
validationFailureAction: Enforce
background: false
rules:
- name: verify-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/myorg/*"
attestors:
- entries:
- keyless:
subject: "https://github.com/myorg/*"
issuer: "https://token.actions.githubusercontent.com"
attestations:
- type: https://slsa.dev/provenance/v1
conditions:
- all:
- key: "{{ builder.id }}"
operator: Equals
value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0"
El Sigstore Policy Controller (anteriormente cosigned) proporciona funcionalidad similar y es mantenido por el proyecto Sigstore. Se integra estrechamente con los workflows de firma keyless y es una excelente opción si tu organización se ha estandarizado en el ecosistema Sigstore.
La combinación de verificación a nivel de pipeline y control de admisión a nivel de clúster crea defensa en profundidad: incluso si una capa es eludida, la otra detecta artefactos no autorizados.
Rollouts Progresivos: Canary, Blue-Green y Feature Flags
Desplegar una nueva versión al 100% del tráfico de forma instantánea es un riesgo de seguridad y confiabilidad. Las estrategias de rollout progresivo te permiten detectar problemas —incluyendo problemas de seguridad— antes de que afecten a todos los usuarios.
Despliegues Canary
Un despliegue canary enruta un pequeño porcentaje del tráfico (por ejemplo, 5%) a la nueva versión mientras la mayoría continúa llegando al release estable. Si métricas como tasas de error, latencia o señales de seguridad (conexiones salientes inesperadas, escalaciones de privilegios elevadas) se degradan, el canary se revierte automáticamente.
Herramientas como Flagger (para Kubernetes), AWS App Mesh e Istio automatizan el análisis canary. Flagger, por ejemplo, puede configurarse para monitorear métricas personalizadas de Prometheus y promover o revertir automáticamente:
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: myapp
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
progressDeadlineSeconds: 600
service:
port: 8080
analysis:
interval: 1m
threshold: 5
maxWeight: 50
stepWeight: 10
metrics:
- name: request-success-rate
thresholdRange:
min: 99
interval: 1m
- name: request-duration
thresholdRange:
max: 500
interval: 1m
Despliegues Blue-Green
Los despliegues blue-green mantienen dos entornos idénticos. El entorno «blue» ejecuta la versión actual; el «green» ejecuta la nueva. El tráfico se cambia de una vez (típicamente vía un load balancer o cambio de DNS) después de que el entorno green pasa las verificaciones de salud y la validación de seguridad. Si algo sale mal, el cambio de vuelta a blue es instantáneo.
El beneficio de seguridad es una ruta de rollback limpia y predecible. No hay estado parcial que analizar, y la versión anterior permanece completamente operativa durante todo el despliegue.
Feature Flags como Controles de Seguridad
Los feature flags desacoplan el despliegue del release. El código se despliega en producción pero permanece inactivo detrás de un flag. Esto le da a los equipos de seguridad un kill switch: si una funcionalidad recién lanzada introduce una vulnerabilidad o se comporta de forma inesperada, puede desactivarse instantáneamente sin un rollback completo. Herramientas como LaunchDarkly, Unleash y OpenFeature proporcionan gestión centralizada de flags con logs de auditoría de quién activó qué y cuándo.
Estrategias de Rollback
Cada plan de despliegue debe incluir un plan de rollback. Cuando las cosas salen mal —y saldrán— la velocidad y confiabilidad de tu rollback determina directamente el radio de impacto.
Rollback Automático por Fallo en Health Check
Kubernetes soporta nativamente el rollback a través de su deployment controller. Si los nuevos pods fallan en las pruebas de readiness o liveness, el rollout se detiene y puede revertirse automáticamente:
# Verificar el estado del rollout y hacer rollback si es necesario
kubectl rollout status deployment/myapp --namespace production --timeout=300s
if [ $? -ne 0 ]; then
echo "Rollout falló, iniciando rollback"
kubectl rollout undo deployment/myapp --namespace production
exit 1
fi
En un modelo GitOps, el rollback significa revertir el commit de Git que introdujo el cambio. El controlador detecta la reversión y reconcilia el clúster de vuelta al estado anterior. Esto preserva la pista de auditoría completa en Git.
Despliegues Inmutables
Los despliegues inmutables tratan cada release como una instancia nueva y desechable. En lugar de actualizar contenedores en su lugar, despliegas un conjunto completamente nuevo de recursos y decomisionas los antiguos. Esto elimina el drift de configuración y asegura que lo que se probó es exactamente lo que se ejecuta en producción. Combinado con digests de imagen (en lugar de tags mutables como latest), los despliegues inmutables garantizan reproducibilidad binaria.
Separación de Identidades de Build y Deploy
Una de las mejoras de seguridad más impactantes que puedes realizar es asegurar que la identidad utilizada para construir artefactos sea diferente de la identidad utilizada para desplegarlos. Esto limita el radio de impacto de un compromiso en cualquiera de las fases.
Credenciales Diferentes
El pipeline de build debería tener credenciales para enviar imágenes a un registry y firmarlas —pero sin acceso a la infraestructura de producción. El pipeline de despliegue (o el controlador GitOps) debería tener credenciales para extraer imágenes y aplicar manifiestos —pero sin acceso a los repositorios de código fuente ni a las claves de firma.
En la práctica, esto significa utilizar service accounts, roles IAM o claims OIDC separados para cada fase. En AWS, el rol de build podría tener permisos para ECR push y firma KMS, mientras que el rol de deploy tiene permisos para EKS y Secrets Manager pero no para ECR push.
Runners Diferentes
Lleva la separación más lejos ejecutando los jobs de build y deploy en runners físicamente diferentes. Los jobs de build se ejecutan en runners efímeros de propósito general. Los jobs de deploy se ejecutan en runners dedicados y reforzados que se encuentran dentro de un perímetro de red más cercano al entorno de producción. Esto previene que un runner de build comprometido pivote hacia producción.
Para un tratamiento más profundo de la separación de identidades y los principios de mínimo privilegio en CI/CD, consulta nuestra guía sobre Separación de Responsabilidades y Mínimo Privilegio en Pipelines CI/CD.
Congelación de Despliegues y Ventanas de Cambio
No todo momento es bueno para desplegar. Las congelaciones de despliegue —períodos durante los cuales los cambios en producción están prohibidos— reducen el riesgo durante eventos de alto tráfico, vacaciones, transiciones de guardia o respuesta activa a incidentes.
Implementa las congelaciones a nivel de plataforma, no solo como un acuerdo de equipo. GitHub Environments soporta deployment branch policies y wait timers. GitLab permite deploy freezes configurados vía la interfaz o API con programaciones estilo cron. Para workflows basados en Kubernetes, puedes aplicar congelaciones con una política de OPA/Gatekeeper o Kyverno que rechace despliegues durante ventanas de tiempo específicas.
# Política Kyverno para aplicar congelación de despliegue
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: deployment-freeze
spec:
validationFailureAction: Enforce
background: false
rules:
- name: block-deployments-during-freeze
match:
any:
- resources:
kinds:
- Deployment
namespaces:
- production
preconditions:
all:
- key: "{{ time_now() }}"
operator: GreaterThan
value: "2026-03-27T00:00:00Z" # Inicio de congelación
- key: "{{ time_now() }}"
operator: LessThan
value: "2026-03-30T00:00:00Z" # Fin de congelación
validate:
message: "Los despliegues en producción están congelados hasta el 30 de marzo. Contacta a platform-team para excepciones de emergencia."
deny: {}
Documenta un proceso de excepción para parches de seguridad de emergencia que necesiten desplegarse durante una congelación, incluyendo quién puede autorizar la excepción y cómo se registra.
Pista de Auditoría: Vinculando Despliegues con Commits, Aprobadores y Ejecuciones de Pipeline
Un workflow de despliegue seguro produce una pista de auditoría completa y a prueba de manipulaciones. Para cada despliegue en producción, deberías poder responder: ¿Qué se desplegó? ¿Quién lo aprobó? ¿Qué pipeline lo construyó? ¿A qué commit se remonta?
Logs de Auditoría a Nivel de Plataforma
AWS CloudTrail registra las llamadas API a EKS, ECS y Lambda, incluyendo quién inició el despliegue y desde qué fuente. GCP Audit Logs proporcionan cobertura similar para GKE y Cloud Run. Asegúrate de que estos logs se envíen a un almacén de logs centralizado e inmutable (como un bucket S3 dedicado con object lock o un SIEM) donde no puedan ser manipulados por un atacante que haya comprometido el entorno de despliegue.
Trazabilidad a Nivel de Pipeline
Anota los recursos de Kubernetes con metadatos de despliegue para que puedas rastrear desde un pod en ejecución hasta la fuente exacta:
# Incluir en tu Helm chart o Kustomize overlay
metadata:
labels:
app.kubernetes.io/version: "{{ .Values.image.tag }}"
annotations:
deploy.example.com/commit-sha: "{{ .Values.commitSha }}"
deploy.example.com/pipeline-url: "{{ .Values.pipelineUrl }}"
deploy.example.com/approved-by: "{{ .Values.approvedBy }}"
deploy.example.com/deployed-at: "{{ now | date \"2006-01-02T15:04:05Z\" }}"
En GitHub Actions, pasa estos valores a través del workflow de despliegue:
- name: Deploy with traceability
run: |
helm upgrade --install myapp ./chart \
--set image.tag=${{ github.sha }} \
--set commitSha=${{ github.sha }} \
--set pipelineUrl="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
--set approvedBy="${{ github.actor }}" \
--namespace production
Monitoreo Post-Despliegue
El despliegue no termina cuando la nueva versión está en ejecución. El monitoreo post-despliegue cierra el ciclo de retroalimentación y detecta problemas que las verificaciones pre-despliegue no detectaron.
Detección de Anomalías
Establece métricas de referencia para el comportamiento normal de la aplicación: tasas de solicitudes, tasas de error, percentiles de latencia, uso de CPU/memoria y patrones de conexión de red. Después de cada despliegue, compara las métricas actuales contra la referencia. Herramientas como Prometheus + Alertmanager, Datadog y Grafana Alerting pueden activar alertas cuando las métricas post-despliegue se desvían más allá de los umbrales.
Desde una perspectiva de seguridad, presta especial atención a conexiones de red salientes inesperadas, nuevos procesos generados dentro de contenedores, llamadas al sistema elevadas y aumentos repentinos en fallos de autenticación. Estos pueden indicar que un artefacto comprometido pasó a través del pipeline.
Métricas DORA para Seguridad
Las cuatro métricas DORA —frecuencia de despliegue, lead time para cambios, tasa de fallo de cambios y tiempo medio de recuperación— se utilizan típicamente para medir el rendimiento de DevOps. Son igualmente valiosas para la seguridad:
- Frecuencia de despliegue indica con qué frecuencia puedes enviar parches de seguridad. Mayor frecuencia significa remediación más rápida.
- Lead time para cambios mide qué tan rápido un fix de seguridad va desde el commit hasta producción. Lead times largos significan ventanas de exposición extendidas.
- Tasa de fallo de cambios rastrea con qué frecuencia los despliegues causan incidentes. Una tasa alta sugiere pruebas o verificación inadecuadas —una preocupación de seguridad.
- Tiempo medio de recuperación (MTTR) mide qué tan rápido puedes hacer rollback o remediar un despliegue fallido. Un MTTR bajo limita el radio de impacto de cualquier incidente, incluyendo una brecha de seguridad.
Rastrea estas métricas por entorno y correlácionolas con eventos de seguridad. Si tu tasa de fallo de cambios se dispara después de adoptar un nuevo patrón de despliegue, investiga antes de que se convierta en un problema de seguridad.
Integrando Todo: Un Pipeline de Despliegue Seguro Completo
Aquí hay un workflow completo de GitHub Actions que incorpora las prácticas discutidas anteriormente —verificación de artefactos, aprobaciones basadas en environments, trazabilidad de despliegue y rollback automático:
# .github/workflows/secure-deploy.yml
name: Secure Deployment
on:
workflow_run:
workflows: ["Build and Sign"]
types: [completed]
branches: [main]
jobs:
verify-and-deploy:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
environment:
name: production
url: https://app.example.com
permissions:
id-token: write
contents: read
steps:
- name: Checkout manifests
uses: actions/checkout@v4
- name: Install cosign
uses: sigstore/cosign-installer@v3
- name: Verify image signature (keyless)
run: |
IMAGE="ghcr.io/myorg/myapp@${{ github.event.workflow_run.head_sha }}"
cosign verify \
--certificate-identity "https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
"$IMAGE"
- name: Verify SLSA provenance
run: |
IMAGE="ghcr.io/myorg/myapp@${{ github.event.workflow_run.head_sha }}"
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
"$IMAGE"
- name: Configure AWS credentials (deploy role)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/deploy-production
aws-region: us-east-1
- name: Deploy to EKS
run: |
aws eks update-kubeconfig --name production-cluster
helm upgrade --install myapp ./chart \
--set image.tag=${{ github.event.workflow_run.head_sha }} \
--set commitSha=${{ github.event.workflow_run.head_sha }} \
--set pipelineUrl="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
--set approvedBy="${{ github.actor }}" \
--namespace production \
--wait --timeout 300s
- name: Verify rollout
run: |
kubectl rollout status deployment/myapp \
--namespace production --timeout=300s
- name: Rollback on failure
if: failure()
run: |
echo "Despliegue fallido — iniciando rollback"
kubectl rollout undo deployment/myapp --namespace production
echo "::error::Despliegue revertido debido a fallo"
Y el pipeline equivalente de GitLab CI con controles similares:
# .gitlab-ci.yml
stages:
- verify
- deploy
- validate
verify_artifact:
stage: verify
image: bitnami/cosign:latest
script:
- cosign verify
--certificate-identity "https://gitlab.com/myorg/myapp//.gitlab-ci.yml@refs/heads/main"
--certificate-oidc-issuer "https://gitlab.com"
$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
rules:
- if: $CI_COMMIT_BRANCH == "main"
deploy_production:
stage: deploy
environment:
name: production
url: https://app.example.com
resource_group: production
needs: [verify_artifact]
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
script:
- aws eks update-kubeconfig --name production-cluster
- helm upgrade --install myapp ./chart
--set image.tag=$CI_COMMIT_SHA
--set commitSha=$CI_COMMIT_SHA
--set pipelineUrl=$CI_PIPELINE_URL
--set approvedBy=$GITLAB_USER_LOGIN
--namespace production
--wait --timeout 300s
validate_deployment:
stage: validate
needs: [deploy_production]
script:
- kubectl rollout status deployment/myapp --namespace production --timeout=300s
after_script:
- |
if [ "$CI_JOB_STATUS" == "failed" ]; then
echo "Revirtiendo despliegue"
kubectl rollout undo deployment/myapp --namespace production
fi
rules:
- if: $CI_COMMIT_BRANCH == "main"
Resumen y Guías Relacionadas
Los workflows de despliegue seguros requieren defensa en profundidad en cada fase: elegir el modelo de despliegue correcto, aplicar gates y aprobaciones, verificar artefactos en el límite del clúster, implementar cambios de forma progresiva, mantener rutas de rollback limpias, separar las identidades de build y deploy, respetar las ventanas de cambio y registrar todo. Ningún control individual es suficiente por sí solo. La combinación de verificación a nivel de pipeline, aplicación de admission controllers, rollouts progresivos y logging de auditoría integral crea un proceso de despliegue que es rápido y seguro a la vez.
Continúa desarrollando tu conocimiento de CI/CD seguro con estas guías relacionadas:
- Separación de Responsabilidades y Mínimo Privilegio en Pipelines CI/CD — Profundización en la separación de identidades, credenciales con alcance limitado y el principio de mínimo privilegio a lo largo de tu pipeline.
- Patrones Defensivos y Mitigaciones para Ataques a Pipelines CI/CD — Contramedidas prácticas para los vectores de ataque más comunes que apuntan a sistemas CI/CD.
