Documentación

Buscar en Arxiu

Escriba para buscar en Arxiu.

Despliegue de Contenedores

Despliega Decision Gate en un entorno de contenedor limitado.

En esta página Sección actual: Contrato de Contenedor Actual

Esta guía describe el contrato actual del contenedor OSS de Decision Gate y proporciona pasos para el operador para construir y ejecutar la imagen del servidor MCP.

La imagen del contenedor es un artefacto del servidor. Ejecuta decision-gate serve y es adecuada para trabajo de integración y calificación similar a producción. No es evidencia de que el compromiso permanente, la recuperación o el perfil de asignación de múltiples nodos esté calificado para el lanzamiento.

Contrato de Contenedor Actual

  • Punto de entrada: decision-gate
  • Comando por defecto: serve --config CONFIG_PATH --allow-non-loopback, donde el preajuste del contenedor utiliza /etc/decision-gate/decision-gate.toml.
  • Montaje de configuración: /etc/decision-gate/decision-gate.toml
  • Transporte: HTTP (SSE opcional)
  • Autenticación: se requiere autenticación de portador; los encabezados de certificado controlados por el llamador o de sujeto de proxy nunca son autoridades de identidad.
  • TLS: terminado en upstream por defecto (server.tls_termination = "upstream")
  • Persistencia: no hay almacenamiento de estado de ejecución duradero por defecto; SQLite es una configuración de persistencia local explícita.
  • Tiempo de ejecución: sin privilegios de root, privilegios mínimos, registros stdout/stderr
  • Rutas escribibles: /var/lib/decision-gate (solo cuando SQLite está habilitado)

La ausencia de un almacenamiento local no hace que las mutaciones del evaluador sean sin estado o seguras para el enrutamiento de múltiples escritores con la misma RunKey. El código actual tiene mecanismos de exactitud de cabeza/idempotencia, pero no se han refinado contra el modelo de ejecución aceptada PF-03 y el perfil de duración del proceso no tiene una reclamación de durabilidad de reinicio. Un despliegue alojado debe enrutar la mutación para una RunKey(namespace, run_id) a través de un proceso resuelto y fijar bytes de ley de escenario idénticos para esa identidad. Esta es una restricción del operador, no una transferencia de autoridad duradera o conmutación por error. Fijar un espacio de nombres completo a un proceso es un enrutamiento conservador actual, no la clave de serialización permanente. El objetivo de múltiples nodos estable en la asignación enruta cada RunKey a una autoridad de evaluador/ejecución aceptada co-localizada y consume testigos externos exactos de la plataforma; consulte el estándar de integración de despliegue.

La configuración del perfil inicial actual no puede representar la adquisición de evidencia de red, fuentes de evidencia MCP remotas, ejecución de subprocesos personalizados o evaluación remota. El transporte del servidor HTTP/SSE lleva solicitudes de herramientas al nodo DG y no habilita esas familias de adquisición excluidas.

Construir la Imagen

Construcción local:

docker build -t decision-gate:dev .

Construcción multi-arquitectura (amd64 + arm64):

IMAGE_REPO=ghcr.io/your-org/decision-gate IMAGE_TAG=dev \
  scripts/container/build_container.sh

Empujar multi-arquitectura:

IMAGE_REPO=ghcr.io/your-org/decision-gate IMAGE_TAG=dev PUSH=1 \
  scripts/container/build_container.sh

Notas:

  • IMAGE_REPO=ghcr.io/your-org/decision-gate es un marcador de posición. Reemplace your-org con su organización o usuario de GitHub (por ejemplo, ghcr.io/decision-gate/decision-gate).
  • IMAGE_TAG=dev es un ejemplo local/dev. Para lanzamientos, use una etiqueta de versión (por ejemplo, vX.Y.Z) y opcionalmente publique latest.

Etiquetas y Política de Lanzamiento

Local/dev:

  • decision-gate:dev para pruebas ad-hoc.
  • Las etiquetas Local/dev no son artefactos de lanzamiento de grado de política.

Lanzamiento:

  • Actualmente no se publica ninguna imagen oficial de GHCR desde este repositorio.
  • Los operadores que deseen una imagen de registro deben construir y subir su propia imagen a un registro controlado por la organización y mantener su propio rastro de procedencia.
  • Los flujos de trabajo de lanzamiento aún emiten evidencia de la cadena de suministro para lanzamientos etiquetados de origen primero y validación de paridad de lanzamiento local.

Configuración

El contenedor espera un archivo de configuración en /etc/decision-gate/decision-gate.toml.

Utiliza el preset de contenedor como base: configs/presets/container-prod.toml.

Requisitos clave:

  • server.bind debe ser no-loopback (por ejemplo, 0.0.0.0:8080).
  • server.auth.mode debe ser bearer_token o mtls.
  • server.tls_termination = "upstream" cuando TLS se termina fuera del contenedor.

Ejecutar el Contenedor

Ejecución mínima (autenticación de token portador, terminación TLS ascendente):

docker run --rm -p 8080:8080 \
  -v "$(pwd)/configs/presets/container-prod.toml:/etc/decision-gate/decision-gate.toml:ro" \
  decision-gate:dev

Notas:

  • Reemplace el token de demostración en la configuración antes de usar en producción.
  • --allow-non-loopback es parte del comando por defecto del contenedor. Si anula el comando, incluya --allow-non-loopback o establezca DECISION_GATE_ALLOW_NON_LOOPBACK=1.

TLS en Contenedor (Opcional)

Si necesitas TLS dentro del contenedor, establece:

[server]
tls_termination = "server"

[server.tls]
cert_path = "/etc/decision-gate/tls/server.crt"
key_path = "/etc/decision-gate/tls/server.key"

Monta los certificados y actualiza tu entorno de ejecución de contenedores en consecuencia.

Modo Duradero (SQLite)

Por defecto, la configuración del contenedor utiliza almacenes en memoria.

Para habilitar la durabilidad de SQLite, actualiza la configuración:

[schema_registry]
type = "sqlite"
path = "/var/lib/decision-gate/schema-registry.db"

[accepted_run_store]
type = "sqlite"
path = "/var/lib/decision-gate/decision-gate.db"
busy_timeout_ms = 5000

Ejecutar con un volumen escribible:

docker run --rm -p 8080:8080 \
  -v "$(pwd)/configs/presets/container-prod.toml:/etc/decision-gate/decision-gate.toml:ro" \
  -v decision-gate-data:/var/lib/decision-gate \
  decision-gate:dev

Expectativas de Autenticación

Ejemplo de token de portador:

curl -sS -X POST http://127.0.0.1:8080/rpc \
  -H "Authorization: Bearer dg-container-demo-token" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Los encabezados de sujeto de certificado afirmados por el llamador no son intencionalmente compatibles. Cuando un proxy o ingreso termina TLS, debe eliminar los encabezados de reenvío no confiables y pasar la credencial portadora revisada sin cambios. TLS terminado en el servidor también protege la conexión, pero no crea un mecanismo de identidad de aplicación separado.

Puntos finales de salud

Decision Gate expone sondas estándar de Kubernetes:

  • GET /healthz para liveness
  • GET /readyz para disponibilidad

Estos puntos finales están intencionadamente no autenticados y devuelven un estado mínimo solamente. /readyz realiza comprobaciones de disponibilidad ligeras (almacenamiento de estado + registro de esquema) y devuelve HTTP 503 con {"status":"not_ready"} si las dependencias no están disponibles.

curl -sS http://127.0.0.1:8080/healthz
curl -sS http://127.0.0.1:8080/readyz

Ambos puntos finales devuelven HTTP 200 con una carga útil JSON.

Ejemplo de Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: decision-gate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: decision-gate
  template:
    metadata:
      labels:
        app: decision-gate
    spec:
      containers:
        - name: decision-gate
          image: ghcr.io/your-org/decision-gate:your-tag
          ports:
            - containerPort: 8080
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            readOnlyRootFilesystem: true
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /readyz
              port: 8080
            initialDelaySeconds: 2
            periodSeconds: 5
          volumeMounts:
            - name: config
              mountPath: /etc/decision-gate/decision-gate.toml
              subPath: decision-gate.toml
              readOnly: true
            - name: data
              mountPath: /var/lib/decision-gate
      volumes:
        - name: config
          configMap:
            name: decision-gate-config
        - name: data
          emptyDir: {}

Para la durabilidad de SQLite, reemplace emptyDir con una reclamación de volumen persistente.

Artefactos de la Cadena de Suministro

Los flujos de trabajo de lanzamiento de Decision Gate generan y verifican artefactos de la cadena de suministro para etiquetas de origen primero y verificaciones de paridad local. Los comandos a continuación siguen siendo útiles para la verificación manual de imágenes construidas por el operador.

Contenedor SBOM (ejemplo usando syft):

syft packages decision-gate:dev -o spdx-json > decision-gate.sbom.spdx.json

Firma de blob o artefacto (cosign):

cosign sign-blob decision-gate.sbom.spdx.json

Declaración de firma de procedencia:

cosign sign-blob decision-gate.provenance.intoto.json

La política de lanzamiento bloquea cuando:

  • Cualquier vulnerabilidad Alta/Crítica está presente.
  • Cualquier CVE conocido y explotado está presente.
  • La verificación de firma o procedencia falla.