Pular para o conteúdo
RootPilotRootPilotRootPilot Edge

Secret stores

O runner lê as credenciais dos seus serviços do seu secret manager, no boot, e as mantém só em memória. Nada é escrito em disco, e nada é custodiado fora da sua infraestrutura.

Terminal window
RUNNER_SECRET_STORE_MODE=env    # default, desenvolvimento
RUNNER_SECRET_STORE_MODE=aws    # AWS Secrets Manager
RUNNER_SECRET_STORE_MODE=vault  # HashiCorp Vault KV v2

Os três backends implementam a mesma interface mínima, get(name), então trocar de um para outro não muda nada no resto do runner.

env: desenvolvimento

Seção intitulada “env: desenvolvimento”

Lê do ambiente do processo. É o default e é o que o Compose alimenta por pass-through ou por runner.secrets.env.

Adequado para desenvolvimento local. Em produção, prefira um dos dois abaixo.

aws: AWS Secrets Manager

Seção intitulada “aws: AWS Secrets Manager”
Terminal window
RUNNER_SECRET_STORE_MODE=aws
# RUNNER_SECRETS_MANAGER_REGION=us-east-1   # ausente ⇒ resolução default do SDK
# RUNNER_SECRETS_MANAGER_PREFIX=rootpilot/  # prefixa o SecretId

Resolve pela cadeia de credenciais default do SDK (IAM role, workload identity, IRSA), sem nenhuma chave estática. É o caminho natural num runner rodando em EKS ou ECS.

O PREFIX prefixa o SecretId, então um segredo chamado DD_API_KEY com prefixo rootpilot/ é buscado como rootpilot/DD_API_KEY.

vault: HashiCorp Vault KV v2

Seção intitulada “vault: HashiCorp Vault KV v2”
Terminal window
RUNNER_SECRET_STORE_MODE=vault
RUNNER_VAULT_ADDR=https://vault.example.com


# auth por token
RUNNER_VAULT_AUTH=token
RUNNER_VAULT_TOKEN=…


# ou auth por AppRole
RUNNER_VAULT_AUTH=approle
RUNNER_VAULT_ROLE_ID=…
RUNNER_VAULT_SECRET_ID=…

Acesso por HTTP à API KV v2. Opções adicionais:

Variável Default Para quê
RUNNER_VAULT_NAMESPACE nenhum Vault Enterprise.
RUNNER_VAULT_KV_MOUNT secret Mount do KV v2.
RUNNER_VAULT_KV_FIELD value Qual campo do secret retornar.
RUNNER_VAULT_PREFIX '' Prefixa o caminho lógico.

O schema recusa configuração incompleta no boot:

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

Segredo ausente não é erro

Seção intitulada “Segredo ausente não é erro”

Nos dois backends remotos, “não encontrado” (ResourceNotFoundException na AWS, 404 no Vault) resolve para undefined, e não para uma exceção.

Isso é o que sustenta o modelo lazy: você configura só os connectors que usa, e os demais simplesmente saem do served-set. Um segredo faltando não derruba o boot.

O sinal disso está no log de boot:

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

Escopo por connector

Seção intitulada “Escopo por connector”

O runtime escopa o secret store por connector: cada um enxerga apenas os segredos que declarou no próprio manifest. Um connector não consegue ler a credencial de outro, mesmo rodando no mesmo processo. É a primeira das quatro garantias do runtime.

O que nunca acontece

Seção intitulada “O que nunca acontece”