Skip to main content
Cada endpoint de segredos verifica uma ação do IAM antes de fazer qualquer coisa. Esta é a lista completa — não há outros, e nenhum endpoint ignora a verificação.
A referência da API mostra a ação na própria página de cada ponto de extremidade, para que você não precise voltar aqui para procurar uma. Ambos vêm do mesmo lugar: a chamada de autorização no serviço, lida no momento da compilação.

​
As ações

Operações em um segredo específico são autorizadas contra CRN desse segredo, com as tags do segredo disponíveis como contexto de condição. Apenas as duas operações de nível de coleção não são.

​
Descrever um segredo não o lê

secrets:GetSecretValue é uma ação diferente de secrets:DescribeSecret, e a divisão é executada por toda a API: a resposta describe não tem nenhum campo de valor, então não há forma em que metadados e texto simples viajam juntos. Conceda a ação de leitura por conta própria, aos poucos principais que precisam dela, nos poucos segredos que precisam. A mesma divisão aparece em KMS com kms:Decrypt e em certificates com certificate:GetCertificateMaterial.

​
Escrever não implica ler

secrets:PutSecretValue adiciona uma versão sem retornar nada da antiga, então um trabalho de rotação pode mantê-la sozinha. Isso vale a pena: um componente que só escreve material novo não tem razão para ser capaz de ler o que já está lá.

​
A listagem não pode ser restringida

secrets:ListSecrets é autorizado contra a coleção em vez de contra segredos individuais, então restringi-lo por CRN ou tag não tem efeito. Escopo secrets:GetSecretValue — esse é o conceito que importa.

​
Recursos

As ações de segredos são verificadas em relação a uma forma de recurso:
O slot de região é preenchido: um segredo vive em uma região e é lido a partir daí. O nome de um segredo pode conter /, e é isso que faz o CRN valer a pena ser analisado. Nomear segredos como prod/payments/stripe-key em vez de prod-payments-stripe-key permite que uma declaração cubra os segredos de um serviço inteiro e nada mais. Os nomes correspondem a ^[a-zA-Z0-9][a-zA-Z0-9._/-]{0,255}$.

​
Condições

Create carrega as tags da solicitação; cada ação com escopo secreto carrega as tags já no secreto:
  • basalt:RequestTag/<key> — o que um chamador pode rotular um segredo como, em create.
  • basalt:ResourceTag/<key> — quais segredos existentes uma ação pode tocar.

​
Escrever uma política

Um serviço lendo exatamente os segredos sob seu próprio prefixo de caminho:
Um trabalho de rotação que pode escrever mas nunca ler:
secrets:* inclui a leitura de todos os valores. Um curinga na ação concede secrets:GetSecretValue junto com tudo o mais, o que raramente é o que se quer dizer com “deixar esta equipe gerenciar segredos”. Liste as ações quando a credencial pertence a uma pessoa ou a um trabalho de CI.
Veja writing policies para o formato do documento, as chaves de condição de tag, e como um guardrail deny sobrevive a um broad allow.

​
Como é uma negação

Uma verificação falhada responde 403:
Ele não diz qual ação estava faltando, deliberadamente — a mensagem é a mesma para cada negação, então não pode ser usada para mapear o que uma credencial pode ou não alcançar. Procure a chamada que você fez na tabela acima, e a ação que ela precisa é a que você adiciona.
Um 404 não é um 403 disfarçado. A propriedade é resolvida antes da autorização: um segredo pertencente a outra conta responde 404 porque não é seu para ver, e um que você possui, mas não tem a ação para respostas 403. Um segredo dentro de sua janela de recuperação é um terceiro caso novamente — ele responde 409 SECRET_DELETED, o que significa que o segredo está lá e a credencial está bem.