Compartir comentarios
Las respuestas se generan en base a la documentación.

Plantillas y ejemplos de políticas

Esta página proporciona ejemplos de políticas completos y listos para funcionar que puedes copiar y adaptar. Los ejemplos se organizan en dos secciones: políticas de inicio rápido para una adopción sencilla, y plantillas de producción para una seguridad integral.

Si eres nuevo en el uso de políticas, te recomendamos comenzar con los tutoriales: Introducción, Validación de imágenes y Validación de Git. Esas páginas enseñan técnicas individuales. Esta página muestra políticas completas que combinan esas técnicas.

Cómo usar estos ejemplos

  1. Copia el código de la política en un archivo Dockerfile.rego junto a tu Dockerfile.
  2. Personaliza los comentarios "todo" con tus valores específicos.
  3. Realiza una prueba ejecutando docker build . y verifica que la política funcione como esperas.
  4. Realiza ajustes según las necesidades de tu equipo.

Uso de ejemplos con bake

Estas políticas funcionan tanto con docker buildx build como con docker buildx bake. En el caso de bake, coloca la política junto a tu Dockerfile y se cargará automáticamente. Para usar políticas adicionales:

target "default" {
  dockerfile = "Dockerfile"
  policy = ["extra.rego"]
}

Consulta la Guía de uso para conocer los detalles completos de la integración con bake.

Inicio rápido

Estas políticas funcionan inmediatamente con una personalización mínima o nula. Utilízalas para adoptar políticas rápidamente y demostrar su valor a tu equipo.

Base ideal para desarrollo

Una política permisiva que permite los flujos de trabajo de desarrollo habituales mientras bloquea problemas de seguridad evidentes.

package docker

default allow := false

allow if input.local
allow if input.git

# Permitir registros públicos comunes
allow if {
  input.image.host == "docker.io"  # Docker Hub
}

allow if {
  input.image.host == "ghcr.io"  # GitHub Container Registry
}

allow if {
  input.image.host == "dhi.io"  # Docker Hardened Images
}

# Requerir HTTPS para todas las descargas
allow if {
  input.http.schema == "https"
}

decision := {"allow": allow}

Esta política permite contextos locales y de Git, imágenes de Docker Hub, GitHub Container Registry y Docker Hardened Images, además de descargas ADD a través de HTTPS. Bloquea las descargas HTTP y los registros no estándar.

Cuándo usarla: Como punto de partida para equipos que se inician en el uso de políticas. Proporciona seguridad básica sin interrumpir los flujos de trabajo de desarrollo.

Lista de permitidos para registros

Controla desde qué registros pueden descargar imágenes tus compilaciones.

package docker

default allow := false

allow if input.local

# TODO: Añade el nombre de host de tu registro interno
allowed_registries := ["docker.io", "ghcr.io", "dhi.io", "registry.company.com"]

allow if {
  input.image.host in allowed_registries
}

# Permitir imágenes DHI replicadas desde Docker Hub (usuarios de DHI Enterprise)
# TODO: Reemplaza con el espacio de nombres (namespace) de tu organización
allow if {
  input.image.host == "docker.io"
  startswith(input.image.repo, "myorg/dhi-")
}

deny_msg contains msg if {
  not allow
  input.image
  msg := sprintf("el registro %s no está en la lista de permitidos", [input.image.host])
}

decision := {"allow": allow, "deny_msg": deny_msg}

Esta política restringe las descargas de imágenes a los registros aprobados. Personalízala y añade tu registro interno a la lista. Si tienes una suscripción a DHI Enterprise y has replicado Docker Hardened Images en Docker Hub, añade una regla para permitir imágenes del espacio de nombres de tu organización.

Cuándo usarla: Para aplicar políticas corporativas sobre fuentes de imágenes aprobadas. Evita que los desarrolladores usen registros públicos arbitrarios.

Fijar imágenes base a digests

Requiere referencias por digest para lograr compilaciones reproducibles.

package docker

default allow := false

allow if input.local

# Requerir referencias por digest para todas las imágenes
allow if {
  input.image.isCanonical
}

deny_msg contains msg if {
  not allow
  input.image
  msg := sprintf("la imagen %s debe usar una referencia por digest (ej., @sha256:...)", [input.image.ref])
}

decision := {"allow": allow, "deny_msg": deny_msg}

Esta política exige que las imágenes utilicen referencias por digest como alpine@sha256:abc123... en lugar de etiquetas como alpine:3.19. Los digests son inmutables: el mismo digest siempre se resuelve en el mismo contenido de imagen.

Cuándo usarla: Para asegurar la reproducibilidad de las compilaciones. Evita que las compilaciones fallen cuando se actualizan las etiquetas en origen (upstream). Obligatorio para el cumplimiento normativo en algunos entornos.

Controlar dependencias externas

Fija versiones específicas de las dependencias que se descargan durante las compilaciones.

package docker

default allow := false

allow if input.local

# Permitir cualquier imagen (añade restricciones según sea necesario)
allow if input.image

# TODO: Añade tus repositorios de Git y etiquetas permitidas
allowed_repos := {
  "https://github.com/moby/buildkit.git": ["v0.26.1", "v0.27.0"],
}
# Solo permitir entrada de Git desde allowed_repos
allow if {
  some repo, versions in allowed_repos
  input.git.remote == repo
  input.git.tagName in versions
}

# TODO: Añade tus descargas permitidas
allow if {
  input.http.url == "https://example.com/app-v1.0.tar.gz"
}

decision := {"allow": allow}

Esta política crea listas de permitidos para dependencias externas. Añade tus repositorios de Git con etiquetas de versión aprobadas y URLs.

Cuándo usarla: Para controlar qué dependencias externas se pueden utilizar en las compilaciones. Evita que las compilaciones descarguen versiones arbitrarias o descargas no verificadas.

Plantillas de producción

Estas plantillas muestran patrones de seguridad integrales. Requieren personalización, pero muestran las mejores prácticas para entornos de producción.

Atestación de imágenes y procedencia

Requiere que las imágenes tengan atestaciones de procedencia de generadores (builders) de confianza.

package docker

default allow := false

allow if input.local

# TODO: Añade los nombres de tus repositorios
allowed_repos := ["myorg/backend", "myorg/frontend", "myorg/worker"]

# Las imágenes de producción necesitan atestaciones completas
allow if {
  some repo in allowed_repos
  input.image.repo == repo
  input.image.hasProvenance
  some sig in input.image.signatures
  trusted_github_builder(sig, repo)
}

# Asistente para validar compilaciones de GitHub Actions desde la rama main
trusted_github_builder(sig, repo) if {
  sig.signer.certificateIssuer == "CN=sigstore-intermediate,O=sigstore.dev"
  sig.signer.issuer == "https://token.actions.githubusercontent.com"
  startswith(sig.signer.buildSignerURI, sprintf("https://github.com/myorg/%s/.github/workflows/", [repo]))
  sig.signer.sourceRepositoryRef == "refs/heads/main"
  sig.signer.runnerEnvironment == "github-hosted"
}

# Permitir Docker Hardened Images con atestaciones integradas
allow if {
  input.image.host == "dhi.io"
  input.image.isCanonical
  input.image.hasProvenance
}

# Permitir imágenes base oficiales con digests
allow if {
  input.image.repo == "alpine"
  input.image.host == "docker.io"
  input.image.isCanonical
}

decision := {"allow": allow}

Esta plantilla valida que las imágenes de tu aplicación tengan atestaciones de procedencia y hayan sido compiladas por GitHub Actions desde tu rama main. Las Docker Hardened Images se permiten al usar digests, ya que incluyen atestaciones completas de forma predeterminada. Otras imágenes base deben usar digests.

Personalización:

  • Reemplaza allowed_repos con los nombres de tus imágenes.
  • Actualiza el nombre de la organización en trusted_github_builder().
  • Añade reglas para otras imágenes base que utilices.

Cuándo usarla: Para aplicar la seguridad de la cadena de suministro en despliegues de producción. Garantiza que las imágenes sean compiladas por pipelines de CI/CD de confianza con procedencia auditable.

Lanzamientos firmados de Git

Aplica el uso de etiquetas firmadas por mantenedores de confianza para dependencias de Git.

package docker

default allow := false

allow if input.local

allow if input.image

# TODO: Reemplaza con la URL de tu repositorio
is_buildkit if {
    input.git.remote == "https://github.com/moby/buildkit.git"
}

is_version_tag if {
    is_buildkit
    regex.match(`^v[0-9]+\.[0-9]+\.[0-9]+$`, input.git.tagName)
}

# Las etiquetas de versión deben estar firmadas
allow if {
    is_version_tag
    input.git.tagName != ""
    verify_git_signature(input.git.tag, "maintainers.asc")
}

# Permitir referencias no firmadas para desarrollo
allow if {
    is_buildkit
    not is_version_tag
}

decision := {"allow": allow}

Esta plantilla requiere que las etiquetas de lanzamiento de producción estén firmadas por mantenedores de confianza. Las ramas y commits de desarrollo pueden no estar firmados.

Configuración:

  1. Exporta las claves públicas PGP de los mantenedores a maintainers.asc:
    $ gpg --export --armor [email protected] [email protected] > maintainers.asc
    
  2. Coloca maintainers.asc en el mismo directorio que tu archivo de política.

Personalización:

  • Reemplaza la URL del repositorio en is_buildkit.
  • Actualiza los mantenedores en el archivo de llavero PGP (keyring).
  • Ajusta el patrón regex de la etiqueta de versión si es necesario.

Cuándo usarla: Para validar que las dependencias de producción provengan de lanzamientos firmados. Protege contra lanzamientos comprometidos o actualizaciones no autorizadas.

Política de registros múltiples

Aplica diferentes reglas de validación para registros internos y externos.

package docker

default allow := false

allow if input.local

# TODO: Reemplaza con el nombre de host de tu registro interno
internal_registry := "registry.company.com"

# Registro interno: validación básica
allow if {
  input.image.host == internal_registry
}

# Registros externos: validación estricta
allow if {
  input.image.host != internal_registry
  input.image.host != ""
  input.image.isCanonical
  input.image.hasProvenance
}

# Docker Hub: lista de permitidos para imágenes específicas
allow if {
  input.image.host == "docker.io"
  # TODO: Añade tus imágenes base aprobadas
  input.image.repo in ["alpine", "golang", "node"]
  input.image.isCanonical
}

# Docker Hardened Images: de confianza por defecto con atestaciones integradas
allow if {
  input.image.host == "dhi.io"
  input.image.isCanonical
}

decision := {"allow": allow}

Esta plantilla define un límite de confianza entre las fuentes de imágenes internas y externas. Las imágenes internas requieren una validación mínima, mientras que las externas necesitan digests y procedencia. Las Docker Hardened Images de dhi.io se tratan como confiables de forma predeterminada ya que incluyen atestaciones completas y garantías de seguridad.

Personalización:

  • Establece el nombre de host de tu registro interno.
  • Añade tus imágenes base aprobadas de Docker Hub.
  • Ajusta los requisitos de validación según tus políticas de seguridad.

Cuándo usarla: Organizaciones con registros internos que necesitan diferentes reglas para fuentes internas y externas. Equilibra la seguridad con las necesidades prácticas del flujo de trabajo.

Política para entornos múltiples

Aplica diferentes reglas según el objetivo (target) o la etapa de compilación. Por ejemplo,

package docker

default allow := false

allow if input.local

# TODO: Define tu lógica de detección de entorno
is_production if {
  input.env.target == "production"
}

is_development if {
  input.env.target == "development"
}

# Producción: reglas estrictas - solo imágenes por digest con procedencia
allow if {
  is_production
  input.image.isCanonical
  input.image.hasProvenance
}

# Desarrollo: reglas permisivas - cualquier imagen
allow if {
  is_development
  input.image
}

# Staging hereda las reglas de producción (detección de target por defecto)
allow if {
  not is_production
  not is_development
  input.image.isCanonical
}

decision := {"allow": allow}

Esta plantilla utiliza los objetivos de compilación para aplicar diferentes niveles de validación. Producción requiere atestaciones y digests, desarrollo es permisivo, y staging utiliza reglas moderadas.

Personalización:

  • Actualiza la lógica de detección del entorno (nombres de target, argumentos de compilación, etc.).
  • Ajusta los requisitos de validación para cada entorno.
  • Añade más entornos según sea necesario.

Cuándo usarla: Equipos con configuraciones de compilación independientes para diferentes etapas de despliegue. Permite flexibilidad en desarrollo mientras aplica reglas estrictas en producción.

Fijación de dependencias completa

Fija todas las dependencias externas a versiones específicas en todos los tipos de entrada.

package docker

default allow := false

allow if input.local

# TODO: Añade tus imágenes fijadas con sus digests exactos
# Las imágenes de Docker Hub usan docker.io como host
allowed_dockerhub := {
  "alpine": "sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412",
  "golang": "sha256:abc123...",
}

allow if {
  input.image.host == "docker.io"
  some repo, digest in allowed_dockerhub
  input.image.repo == repo
  input.image.checksum == digest
}

# TODO: Añade tus imágenes DHI fijadas
allowed_dhi := {
  "python": "sha256:def456...",
  "node": "sha256:ghi789...",
}

allow if {
  input.image.host == "dhi.io"
  some repo, digest in allowed_dhi
  input.image.repo == repo
  input.image.checksum == digest
}

# TODO: Añade tus dependencias Git fijadas
allowed_git := {
  "https://github.com/moby/buildkit.git": {
    "tag": "v0.26.1",
    "commit": "abc123...",
  },
}

allow if {
  some url, version in allowed_git
  input.git.remote == url
  input.git.tagName == version.tag
  input.git.commitChecksum == version.commit
}

# TODO: Añade tus descargas HTTP fijadas
allowed_downloads := {
  "https://releases.example.com/app-v1.0.tar.gz": "sha256:def456...",
}

allow if {
  some url, checksum in allowed_downloads
  input.http.url == url
  input.http.checksum == checksum
}

decision := {"allow": allow}

Esta plantilla fija cada dependencia externa a versiones exactas con verificación criptográfica. Las imágenes usan digests, los repositorios de Git usan hashes de commit y las descargas usan sumas de comprobación.

Personalización:

  • Añade todas tus dependencias con sus versiones/sumas de comprobación exactas.
  • Mantén actualizado este archivo al modificar las dependencias.
  • Considera automatizar las actualizaciones a través de CI/CD.

Cuándo usarla: Máxima reproducibilidad y seguridad. Garantiza que las compilaciones utilicen siempre versiones exactas de todas las dependencias. Obligatorio para entornos de alta seguridad o regulados.

Verificación manual de firmas

Verifica las firmas de las imágenes inspeccionando los campos de metadatos de las firmas.

package docker

default allow := false

allow if input.local

# Requerir firmas válidas de GitHub Actions
allow if {
    input.image
    input.image.hasProvenance
    some sig in input.image.signatures
    valid_github_signature(sig)
}

# Función auxiliar para validar firmas de GitHub Actions
valid_github_signature(sig) if {
    # Firma sin llave (keyless) de Sigstore
    sig.signer.certificateIssuer == "CN=sigstore-intermediate,O=sigstore.dev"
    sig.signer.issuer == "https://token.actions.githubusercontent.com"

    # TODO: Reemplaza con tu organización
    startswith(sig.signer.buildSignerURI, "https://github.com/myorg/.github/workflows/")
    startswith(sig.signer.sourceRepositoryURI, "https://github.com/myorg/")

    # Verificar el ejecutor (runner) alojado en GitHub
    sig.signer.runnerEnvironment == "github-hosted"

    # Requerir marca de tiempo (timestamp)
    count(sig.timestamps) > 0
}

decision := {"allow": allow}

Esta política valida que las imágenes hayan sido compiladas por GitHub Actions utilizando la firma sin clave (keyless) de Sigstore.

Personalización:

  • Reemplaza myorg con tu organización de GitHub.
  • Ajusta las restricciones de ruta del flujo de trabajo.
  • Añade comprobaciones de campos de firma adicionales según sea necesario.

Cuándo usarla: Para asegurar que las imágenes sean compiladas por la CI/CD con firmas verificables, y no subidas manualmente por los desarrolladores.

Siguientes pasos