Secret stores

El runner lee las credenciales de tus servicios desde tu secret manager, en el boot, y las mantiene solo en memoria. No se escribe nada en disco, y nada queda bajo custodia fuera de tu infraestructura.

RUNNER_SECRET_STORE_MODE=env    # default, development
RUNNER_SECRET_STORE_MODE=aws    # AWS Secrets Manager
RUNNER_SECRET_STORE_MODE=vault  # HashiCorp Vault (KV v2 or v1)

Los tres backends implementan la misma interfaz mínima, get(name), así que cambiar de uno a otro no cambia nada más en el runner.

Cuál elegir

En AWS: usa aws. Es nativo, y la autenticación sale de la identidad de la propia carga de trabajo.

En GCP, o en cualquier otro lugar: usa vault. No existe un backend nativo de GCP Secret Manager: si estás en GCP, Vault es el camino soportado. Ten en cuenta que esto es ortogonal a obtener credenciales para GCP destinadas a los connectors, que funciona de forma nativa mediante Workload Identity (RUNNER_GCP_CRED_MODE=chain, en Credenciales de nube).

env no es un camino de producción: las claves quedan en texto plano en la definición de la carga de trabajo.

Dos capas distintas, y no hay que confundirlas

La capa 1 es esta página: dónde viven los secretos. La capa 2 es cómo el runner obtiene credenciales de nube para los connectors de lectura: RUNNER_AWS_CRED_MODE y RUNNER_GCP_CRED_MODE, en Credenciales de nube. Son ortogonales.

env: desarrollo

Lee del entorno del proceso. Es el valor por defecto, y Compose lo alimenta por pass-through: el valor viene del shell, inyectado por tu secret manager o por runner.secrets.env vía npm run dev:runner:file.

Sirve para desarrollo local. En producción, prefiere uno de los dos de abajo.

aws: AWS Secrets Manager

RUNNER_SECRET_STORE_MODE=aws
# RUNNER_SECRETS_MANAGER_REGION=us-east-1   # absent ⇒ SDK default resolution
# RUNNER_SECRETS_MANAGER_PREFIX=whystack/  # prefixes the SecretId

Resuelve mediante la cadena de credenciales por defecto del SDK (IAM role, workload identity, IRSA), sin claves estáticas. Es el camino natural para un runner en EKS o ECS.

PREFIX antepone un prefijo al SecretId, así que un secreto llamado DD_API_KEY con el prefijo whystack/ se busca como whystack/DD_API_KEY.

vault: HashiCorp Vault (KV v2 y v1)

RUNNER_SECRET_STORE_MODE=vault
RUNNER_VAULT_ADDR=https://vault.example.com

# token auth
RUNNER_VAULT_AUTH=token
RUNNER_VAULT_TOKEN=…

# or AppRole auth
RUNNER_VAULT_AUTH=approle
RUNNER_VAULT_ROLE_ID=…
RUNNER_VAULT_SECRET_ID=…

# or Kubernetes auth, the method that belongs in a cluster
RUNNER_VAULT_AUTH=kubernetes
RUNNER_VAULT_K8S_ROLE=whystack
# optional; default below
RUNNER_VAULT_K8S_TOKEN_PATH=/var/run/secrets/tokens/vault/token

En Kubernetes, prefiere kubernetes antes que approle

AppRole requiere entregarle al contenedor un secret_id estático, exactamente el tipo de credencial que el WhyStack Agent existe para no cargar. El login por Kubernetes usa el token proyectado de la service account del propio pod: la identidad de la carga de trabajo es la credencial, y nada estático viaja en la imagen.

El pod tiene que montar el token, y el audience tiene que ser el que espera tu Vault:

volumes:
  - name: vault-token
    projected:
      sources:
        - serviceAccountToken:
            path: token
            audience: vault      # whatever your Vault role requires
            expirationSeconds: 3600
volumeMounts:
  - name: vault-token
    mountPath: /var/run/secrets/tokens/vault
    readOnly: true

Usa un mount separado del token de enrollment. Las dos proyecciones llevan audiences distintas; reutilizar un mismo archivo hace que uno de los lados rechace un token legítimo, y el error se lee como una credencial inválida.

Acceso HTTP a la API del KV. La versión del mount (v2 o v1) se detecta en la primera lectura, así que un mount v1 ya no se confunde con un secreto ausente. Opciones adicionales:

Variable	Por defecto	Para qué
RUNNER_VAULT_NAMESPACE	ninguno	Vault Enterprise.
RUNNER_VAULT_KV_MOUNT	secret	Mount del KV. v2 y v1 se detectan automáticamente.
RUNNER_VAULT_KV_FIELD	value	Qué campo del secreto devolver.
RUNNER_VAULT_PREFIX	''	Antepone un prefijo a la ruta lógica.

El esquema rechaza la configuración incompleta en el boot:

RUNNER_SECRET_STORE_MODE=vault requires RUNNER_VAULT_ADDR
vault auth requires RUNNER_VAULT_TOKEN (token), RUNNER_VAULT_ROLE_ID+RUNNER_VAULT_SECRET_ID (approle) or RUNNER_VAULT_K8S_ROLE (kubernetes)

Un secreto ausente no es un error

En los dos backends remotos, “no encontrado” (ResourceNotFoundException en AWS, 404 en Vault) se resuelve como undefined, no como una excepción.

Eso es lo que hace funcionar el modelo lazy: configuras solo los connectors que usas, y los demás simplemente salen del served set. Un secreto ausente no tumba el boot.

La señal está en el log de boot:

connector not served {connectorId: "azion", missing: ["AZION_TOKEN"]}

Un error de tipeo en el nombre de una clave se ve exactamente igual que una clave ausente

El connector azion declara AZION_TOKEN. Si tu bóveda tiene AZION_API_TOKEN, el resultado es idéntico a no tener nada: el connector sale del served set, en silencio. Revisa los nombres exactos en Credenciales por connector.

Alcance por connector

El runtime limita el alcance del secret store por connector: cada uno ve solo los secretos que declaró en su propio manifest. Un connector no puede leer la credencial de otro, aunque corra en el mismo proceso. Es la primera de las cuatro garantías del runtime.

Lo que nunca pasa

Política inviolable

Las credenciales del cliente nunca quedan bajo custodia fuera de la infraestructura del cliente. El runner las lee de su secret manager en el boot y las mantiene solo en memoria. No hay ningún camino en el código por el que una credencial cruce la frontera hacia el control-plane.