Autorização de acesso

Quando um step pede algo além de leitura, o Oren pergunta antes de executar:

write-report-sh solicita acesso:
  medium    workspace  directory escrita /work
  critical  docker     engine/docker /var/run/docker.sock (da implementação, não do contrato)

Conceder 2 acessos a este step? [s/N]

Repare no (da implementação, não do contrato): aquela dependência não é exigida pela task — é escolha de quem a implementou. Outra implementação do mesmo contrato pode não precisar dela.

A resposta é gravada

Em .oren/consent.json, e feito para ser commitado:

{
  "version": 1,
  "grants": {
    "c887c99929c347fb": {
      "task": "exemplo/write-report@1.0.0",
      "implementation": "exemplo/write-report-sh@1.0.0",
      "image": "docker.io/library/alpine@sha256:d9e853...",
      "dependencies": [
        { "name": "workspace", "type": "directory", "privilege": "medium" }
      ]
    }
  }
}

Commitado, o time inteiro herda a decisão — e uma escalada de privilégio aparece como diff em code review. Revisão de privilégio deixa de ser um prompt que alguém aceita sem ler e vira parte do fluxo que já existe.

O que invalida uma autorização

A chave cobre a identidade do worker e o conjunto de dependências. Qualquer um destes obriga nova autorização:

• imagem diferente (por digest, não por tag)
• dependência nova
• diretório que passou a ser mutável

Como a identidade vem do oren.lock, republicar uma tag com outro conteúdo não herda a autorização anterior.

Autorizar sem executar

oren authorize entrega --properties main

Ele resolve o pipeline, mostra o que cada step pede, pergunta e grava — e não executa nada. Nenhum container sobe.

É o comando a usar antes do primeiro CI. A alternativa seria “rode o pipeline localmente uma vez”, que num pipeline de entrega significa construir, publicar, entregar e comitar — um deploy de produção da sua máquina, para registrar uma autorização.

Ele pergunta, então precisa de um terminal: não funciona com a entrada redirecionada nem dentro de um job de CI.

As propriedades decidem o que é perguntado

Steps desligados por enabled não são autorizados — eles não vão rodar. Se o seu main tem um step que o develop não tem, autorizar com --properties develop não cobre o CI da main.

O comando mostra os pulados por isso: é a explicação de “autorizei e continuou pedindo”.

Em CI

Sem terminal e sem autorização gravada, o pipeline falha:

erro  Step "report" exige autorização e não há terminal interativo
  Rode o pipeline localmente uma vez para autorizar e commite o arquivo
  .oren/consent.json, ou passe --yes para autorizar sem confirmação.

Privilégio novo não é concedido sozinho. --yes existe, mas é uma decisão explícita sua — e no CI ela vale pouco: o consent.json não volta do runner, então cada execução reautoriza e o registro deixa de significar algo.

O caminho que funciona é oren authorize na sua máquina, e o .oren/consent.json commitado junto com o oren.lock e o .oren/registry/. Os três descrevem a mesma decisão: um lock apontando para uma imagem que o consent não autorizou para o CI parado, pedindo autorização.

Sem cerimônia desnecessária

Dependência de privilégio baixo — um diretório somente leitura — não pergunta. Cerimônia demais é o que faz o mecanismo deixar de ser lido.