Este laboratório foi desenvolvido com nossa parceira, a Hashicorp. Se você optou por receber atualizações, anúncios e ofertas de produtos no seu Perfil da Conta, suas informações pessoais poderão ser compartilhadas com a Hashicorp, patrocinadora do laboratório.

GSP1004

Visão geral

O Vault usa políticas para administrar o comportamento dos clientes e estabelecer o controle de acesso baseado em função (RBAC) especificando privilégios de acesso (autorização). As políticas oferecem uma maneira declarativa de conceder ou proibir o acesso a determinados caminhos e operações. Neste laboratório, você vai aprender a escrever e usar políticas do Vault.

Objetivos

Neste laboratório, você vai:

• Criar políticas do Vault
• Gerenciar políticas do Vault
• Associar políticas do Vault
• Verificar e testar políticas do Vault

Configuração e requisitos

Antes de clicar no botão Começar o Laboratório

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é ativado quando você clica em Iniciar laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, e não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

• Acesso a um navegador de Internet padrão (recomendamos o Chrome).

Observação: para executar este laboratório, use o modo de navegação anônima (recomendado) ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório: não se esqueça que, depois de começar, não será possível pausar o laboratório.

Observação: use apenas a conta de estudante neste laboratório. Se usar outra conta do Google Cloud, você poderá receber cobranças nela.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. Clique no botão Começar laboratório. Se for preciso pagar por ele, uma caixa de diálogo vai aparecer para você selecionar a forma de pagamento. À direita, você encontra o painel Configuração e acesso ao laboratório com as seguintes informações:

   • O botão Abrir console do Google Cloud
   • As credenciais temporárias (nome de usuário e senha) que você vai usar no laboratório
   • Outros dados, se necessários

   O timer do laboratório fica na parte de cima da página e mostra o tempo restante.

2. Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.

   O laboratório ativa os recursos e depois abre a página "Login" em outra guia.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Login.

   {{{user_0.username | "Username"}}}

   Você também encontra o nome de usuário no painel Configuração e acesso ao laboratório.

4. Clique em Avançar.

5. Copie a Senha abaixo e cole na caixa de diálogo Olá!.

   {{{user_0.password | "Password"}}}

   Você também encontra a senha no painel Configuração e acesso ao laboratório.

6. Clique em Avançar.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, talvez receba cobranças adicionais.

7. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes sem custo financeiro.

Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.

Observação: para acessar os produtos e serviços do Google Cloud, clique no Menu de navegação ou digite o nome do serviço ou produto no campo Pesquisar.

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. Clique em Ativar o Cloud Shell na parte de cima do console do Google Cloud.

2. Clique nas seguintes janelas:

   • Continue na janela de informações do Cloud Shell.
   • Autorize o Cloud Shell a usar suas credenciais para fazer chamadas de APIs do Google Cloud.

Depois de se conectar, você verá que sua conta já está autenticada e que o projeto está configurado com seu Project_ID, . A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

A gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

3. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

4. Clique em Autorizar.

Saída:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Opcional) É possível listar o ID do projeto usando este comando:

gcloud config list project

Saída:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Observação: consulte a documentação completa da gcloud no Google Cloud no guia de visão geral da gcloud CLI.

Tarefa 1: instalar o Vault

1. No Cloud Shell, adicione a chave GPG da HashiCorp:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - Observação: se algum aviso for exibido, ignore-o.

2. Adicione o repositório Linux oficial da HashiCorp:

sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

3. Atualize e instale o Vault:

sudo apt-get update sudo apt-get install vault

Verificar a instalação

Depois de instalar o Vault, verifique a disponibilidade do binário dele para confirmar se a instalação funcionou.

• Execute o comando vault para verificar a instalação:

vault

A resposta será um conteúdo de ajuda parecido com este:

Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases monitor Stream log messages from a Vault server namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

Tarefa 2: iniciar o servidor do Vault

Depois de instalar o Vault, a próxima etapa é iniciar um servidor dele.

O Vault funciona como um aplicativo cliente/servidor. O servidor do Vault é a única parte da arquitetura dele que interage com o armazenamento de dados e os back-ends. Todas as operações feitas pela CLI do Vault interagem com o servidor por uma conexão TLS.

Neste laboratório, você vai iniciar e interagir com o servidor do Vault em execução no modo de desenvolvimento (em inglês).

Esse servidor de modo de desenvolvimento não exige mais nenhuma configuração, e a CLI do Vault local será autenticada para se comunicar com ele. Com isso, fica fácil testar o Vault ou iniciar uma instância dele em um ambiente de desenvolvimento. Todos os recursos do Vault estão disponíveis no modo "dev". A flag -dev simplesmente pula várias etapas de configuração e adota padrões não seguros.

Aviso: nunca execute um servidor no modo "dev" em produção. Ele não é seguro e perde dados a cada reinicialização, por armazenar dados na memória. Ele serve apenas para desenvolvimento ou teste.

Como iniciar o servidor de desenvolvimento

Inicie um servidor de desenvolvimento do Vault. O servidor de desenvolvimento é um servidor integrado e pré-configurado que não é muito seguro, mas é útil para usar o Vault localmente.

1. Para iniciar o servidor de desenvolvimento do Vault, execute:

vault server -dev

O resultado deve ser relacionado à configuração do servidor do Vault. Os valores Unseal Key e Root Token são exibidos:

==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: info Mlock: supported: false, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.4.1 WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variable: $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0= Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6x Development mode should NOT be used in production installations! Observação: o servidor de desenvolvimento armazena todos os dados criptografados na memória, detecta em localhost sem TLS, além de desbloquear automaticamente e mostrar a chave de desbloqueio e a chave de acesso raiz. Observação: operação não segura

Não execute um servidor de desenvolvimento do Vault em produção. Usamos essa abordagem apenas para simplificar o processo de desbloqueio para esta demonstração.

Com o servidor de desenvolvimento do Vault em execução, continue a configurar o acesso a ele.

2. Abra uma nova guia do Cloud Shell.

3. Copie e execute o comando export VAULT_ADDR .. do resultado do terminal. Isso configura o cliente do Vault para se comunicar com o servidor de desenvolvimento:

export VAULT_ADDR='http://127.0.0.1:8200'

A CLI do Vault determina quais servidores do Vault devem enviar solicitações usando a variável de ambiente VAULT_ADDR.

Verificar se o servidor está em execução

• Verifique se o servidor está em execução com o comando vault status:

vault status

Se a execução funcionar, o resultado será semelhante a este:

$ vault status Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.13.2 Build Date 2023-04-25T13:02:50z Storage Type inmem Cluster Name vault-cluster-e2392b81 Cluster ID 48d7aba0-5416-a36b-2c27-0b256b222f57 HA Enabled false

Ótimo. Você iniciou o servidor de desenvolvimento do Vault. Continue para a próxima seção, onde vai aprender a escrever políticas do Vault.

Tarefa 3: políticas do Vault

O Vault cria uma política root (em inglês) durante a inicialização. A política root realiza todas as operações em todos os caminhos. Essa política é atribuída ao token root que aparece quando a inicialização é concluída. Isso cria um superusuário inicial para ativar mecanismos de Secrets, definir políticas e configurar métodos de autenticação.

O Vault também cria uma política default (em inglês). A política "default" define um conjunto comum de recursos que permite ao token analisar e gerenciar a si mesmo. Essa política também é atribuída ao token root e anexada a todos os tokens por padrão.

Sintaxe da política

As políticas são escritas em HCL ou JSON e descrevem quais caminhos do Vault um usuário ou máquina tem permissão para acessar. Uma política define uma lista de caminhos. Cada caminho expressa os recursos permitidos. Os recursos de um caminho precisam ser concedidos, já que o Vault nega recursos aos caminhos para se manter seguro por padrão.

Este é o formato básico de uma política:

path "<path>" { capabilities = ["list of capabilities"] }

Esta é uma política muito simples que concede recursos de leitura ao caminho "secret/foo":

path "secret/foo" { capabilities = ["read"] }

Quando essa política é atribuída a um token, ele pode ler em "secret/foo". No entanto, o token não pode atualizar ou excluir "secret/foo", porque os recursos não permitem isso. Como as políticas são negadas por padrão, o token não teria outro acesso no Vault. Isso significa que uma política vazia do Vault não concede permissão no sistema.

Recursos

Uma política define um ou mais caminhos e uma lista de recursos (em inglês) permitidos. Cada caminho precisa definir um ou mais recursos que fornecem controle detalhados sobre as operações permitidas ou negadas. Como mostrado nos exemplos abaixo, os recursos são sempre especificados como uma lista de strings, mesmo que haja apenas um recurso. A maioria desses recursos é associada aos verbos HTTP compatíveis com a API Vault. Esta é a lista de recursos:

Recurso da política	Verbos HTTP associados
create	POST/PUT
read	GET
update	POST/PUT
delete	DELETE
list	LIST
patch	PATCH
sudo	-
deny	-

O recurso sudo permite o acesso a caminhos protegidos por "root". Consulte a seção do tutorial Endpoints protegidos por "root" (em inglês). O recurso deny desativa o acesso ao caminho. Quando combinado com outros recursos, ele sempre tem precedência.

Exemplos de políticas

Defina uma política mais detalhada para conceder acesso total a "secret/*" desta forma:

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] }

Para definir mais restrições, adicione o recurso deny:

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/super-secret" { capabilities = ["deny"] }

Mesmo que secret/* tenha permissão, a linha nega explicitamente o acesso a secret/super-secret. Essa negação tem precedência.

As políticas também podem especificar parâmetros permitidos, não permitidos e obrigatórios. A chave "secret/restricted" só pode conter foo (qualquer valor) e bar (um de zip ou zap).

path "secret/restricted" { capabilities = ["create"] allowed_parameters = { "foo" = [] "bar" = ["zip", "zap"] } }

As políticas testam o conjunto de recursos em relação a uma solicitação pela correspondência baseada em caminho. Uma política path pode especificar um caminho exato para correspondência ou um padrão glob que instrui o Vault a usar uma correspondência de prefixo.

Por exemplo, esta política permite ler apenas "secret/foo" ou "secret/foo/bar".

path "secret/foo" { capabilities = ["read"] }

E esta política permite ler tudo em "secret/bar". Um token anexado pode ler "secret/bar/zip", "secret/bar/zip/zap", mas não "secret/bars/zip".

path "secret/bar/*" { capabilities = ["read"] }

Esta política permite ler tudo que tenha o prefixo "zip-". Um token anexado pode ler "secret/zip-zap" ou "secret/zip-zap/zong", mas não "secret/zip/zap.

path "secret/zip-*" { capabilities = ["read"] }

Por fim, o caractere + pode ser usado para indicar qualquer número de caracteres limitado a um único segmento de caminho. O exemplo abaixo permite a leitura do caminho "teamb" em qualquer caminho de nível superior em secret/.

path "secret/+/teamb" { capabilities = ["read"] }

E este exemplo permite a leitura de secret/foo/bar/teamb, secret/bar/foo/teamb etc.

path "secret/+/+/teamb" { capabilities = ["read"] }

Como você pode ver, a arquitetura do Vault é semelhante a um sistema de arquivos. Cada ação no Vault tem um caminho e um recurso correspondentes. Até mesmo os endpoints de configuração principais internos do Vault ficam no caminho "sys/". As políticas definem o acesso a esses caminhos e recursos, o que controla o acesso de um token às credenciais no Vault.

Políticas com modelos

A sintaxe de políticas permite a substituição de variáveis em algumas strings de políticas com valores disponíveis para o token. Atualmente, as informações de identity podem ser injetadas, e as chaves path nas políticas permitem a injeção. Por enquanto, não se preocupe com entidades ou aliases. Isso serve apenas para referência posterior.

Parâmetros

Nome	Descrição
identity.entity.id	O ID da entidade
identity.entity.name	O nome da entidade
identity.entity.metadata.<metadata key>	Metadados associados à entidade da chave especificada
identity.entity.aliases.<mount accessor>.id	ID do alias da entidade da montagem especificada
identity.entity.aliases.<mount accessor>.name	Nome do alias da entidade da montagem especificada
identity.entity.aliases.<mount accessor>.metadata.<metadata key>	Metadados associados ao alias da montagem e da chave de metadados especificadas
identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>	Metadados personalizados associados ao alias da montagem e da chave de metadados personalizada especificadas
identity.groups.ids.<group id>.name	O nome do grupo para o ID especificado
identity.groups.names.<group name>.id	O ID do nome de grupo especificado
identity.groups.ids.<group id>.metadata.<metadata key>	Metadados associados ao grupo da chave especificada
identity.groups.names.<group name>.metadata.<metadata key>	Metadados associados ao grupo da chave especificada

Exemplos

Esta política cria uma seção do mecanismo de Secrets KVv2 para um usuário específico:

path "secret/data/{{identity.entity.id}}/*" { capabilities = ["create", "update", "read", "delete"] } path "secret/metadata/{{identity.entity.id}}/*" { capabilities = ["list"] }

Para mais informações, consulte a documentação de políticas com modelos (em inglês).

Observação: ao desenvolver políticas com modelos, use IDs sempre que possível. Cada ID é exclusivo do usuário, enquanto os nomes podem mudar com o tempo e ser reutilizados. Dessa forma, se o nome de um usuário ou grupo for alterado, a política será associada à entidade ou ao grupo correto.

Verificar os recursos integrados de políticas

Depois de saber como as políticas são escritas, vamos conferir rapidamente os recursos das políticas root e default.

1. Na guia aberta do Cloud Shell, execute este comando para fazer login no Vault com seu token root:

vault login token=<your root token>

Este resultado deve ser exibido:

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.mCWmZyVNi6ZDU7HSq7vQXwvj token_accessor nFDgTnm7FYCHNLSERwiVsbWf token_duration ∞ token_renewable false token_policies ["root"] identity_policies [] policies ["root"] Observação: a política anexada é a política root.

2. Como a política "root" permite que você faça qualquer coisa no Vault, execute um comando básico para confirmar isso:

vault secrets list

O resultado deve ser semelhante a este:

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_f0f2e28e per-token private secret storage identity/ identity identity_a554d41f identity store secret/ kv kv_ca28f047 key/value secret storage sys/ system system_1a7dcf93 system endpoints..

Tente executar o mesmo comando como um usuário, com apenas a política padrão anexada.

3. Ative o método de autenticação userpass e crie um novo usuário:

vault auth enable userpass vault write auth/userpass/users/example-user password=password!

4. Faça login no Vault com o novo usuário:

vault login -method=userpass username=example-user password=password!

O resultado vai ser o seguinte:

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.Ov9GkScxp5AYDjzmbdHNN4r0 token_accessor UewGCCotUMjccmD1EjssgHqf token_duration 768h token_renewable true token_policies ["default"] identity_policies [] policies ["default"] token_meta_username example-user Observação: a política anexada é a default.

5. Execute o mesmo comando de antes para verificar os recursos da política:

vault secrets list

Este erro será exibido:

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

Como mostrado aqui, o Vault está fazendo uma solicitação de API GET para o caminho sys/mounts. Como um erro de permissão negada foi exibido, não é possível acessar o caminho e listar os mecanismos de Secrets. Você vai escrever sua primeira política para acessar esse caminho e listar os mecanismos de Secrets.

Tarefa 4: criar uma política

Como o Vault protege, armazena e controla o acesso a Secrets de forma centralizada em infraestruturas e aplicativos distribuídos, é fundamental controlar as permissões antes que qualquer usuário ou máquina tenha acesso.

A solução é restringir o uso da política "root" e escrever políticas detalhadas para praticar o privilégio mínimo. Por exemplo, se um aplicativo recebe credenciais do Google Cloud pelo Vault, crie concessões de política para ler pelo mecanismo de Secrets do Google Cloud, mas não para excluir etc.

As políticas são anexadas a tokens e papéis para aplicar permissões de cliente no Vault. Como você já viu como as políticas são definidas sintaticamente, você vai escrever sua primeira política do Vault.

Fazer login na interface da web do Vault

1. Primeiro, clique no ícone de visualização na web na barra de ferramentas do Cloud Shell.

2. Clique em Alterar porta.

3. Mude o número da porta para 8200 e clique em Alterar e visualizar.

4. A página de login no Google será aberta.

5. Insira o token root salvo anteriormente no laboratório e clique em Sign in.

Seu servidor de desenvolvimento no Vault deve ser semelhante ao exemplo abaixo.

Depois de fazer login na interface da web do servidor de desenvolvimento, prossiga para a próxima seção.

Criar uma nova política

1. Clique em Access control na página inicial. As políticas de ACL default e root serão exibidas.

2. Clique em Create ACL policy.

3. Defina demo-policy como o nome da política.

Agora você pode escrever sua política. Na seção anterior, você não conseguiu acessar o caminho sys/mounts para ler os mecanismos de Secrets. Agora, você pode adicioná-lo.

4. Em Policy rules, selecione Code editor e adicione este código de marcador de posição:

path "path" { capabilities = [""] }

5. Atualize o path como o caminho sys/mounts que você tentou acessar antes:

path "sys/mounts" { capabilities = [""] }

6. Adicione um recurso. Como o Vault está tentando fazer uma chamada de API GET nesse caminho, você precisa ter o recurso read. Adicione read à lista de recursos:

path "sys/mounts" { capabilities = ["read"] }

Sua política deve ser semelhante a esta:

7. Clique em Create policy.

Associe essa política ao example-user criado anteriormente.

8. Clique em Back to main navigation.

9. Clique em Access > Authentication methods no painel esquerdo e, em seguida, em userpass.

10. Clique nos três pontos ao lado do usuário example-user e selecione Edit user.

11. Abaixo do campo de senha, clique em Tokens para abrir o submenu.

12. Em Generated Token's Policies, adicione a política que você acabou de criar (demo-policy) e clique em Add.

13. Clique em Save.

Ótimo. Você criou uma nova política e a associou ao example-user.

14. Volte para o Cloud Shell e execute este comando novamente:

vault secrets list

O mesmo erro de antes será exibido:

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

Por que ocorreu um erro depois de adicionar a política ao usuário? Isso acontece porque, depois de associar uma nova política a um usuário, essa política não será associada ao token desse usuário. Para corrigir isso, gere um novo token para o usuário para que a nova política seja anexada a esse token.

15. Execute este comando para fazer login e gerar um novo token para example-user:

vault login -method=userpass username=example-user password=password! Observação: o resultado vai exibir um novo token. As políticas default e demo-policy estão anexadas. Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.7AVelOPORi1zhjH5iLototw7 token_accessor H1ee2gTXzTXUU9ptpU3ailnJ token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username example-user

16. Tente listar os mecanismos de Secrets mais uma vez:

vault secrets list

O resultado será semelhante a este:

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_76cb59ae per-token private secret storage identity/ identity identity_7fa27e52 identity store secret/ kv kv_f6e83366 key/value secret storage sys/ system system_414d50aa system endpoints..

17. Também é possível usar o comando vault token capabilities para verificar os recursos do token. Execute este comando para verificar sua política no caminho sys/mounts:

vault token capabilities <your token> sys/mounts

Este resultado será exibido:

read

18. Verifique os recursos do token para o caminho sys/policies/acl:

vault token capabilities <your token> sys/policies/acl

Este resultado será exibido:

deny

19. Para verificar isso, tente executar este comando para listar as políticas:

vault policy list

Este erro será exibido:

Error listing policies: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/policies/acl?list=trueCode: 403. Errors: * 1 error occurred: * permission denied

Você recebeu um erro de permissão negada para uma solicitação de API GET no caminho sys/policies/acl. O caminho também contém list=true. Também será necessário adicionar esse recurso. Para corrigir isso, atualize a política.

20. Volte para a demo-policy criada na interface do Vault.

21. Clique em Edit policy.

22. Na caixa Policy, adicione este código de marcador de posição abaixo da política que você escreveu:

path "path" { capabilities = [""] }

23. Atualize o path para o caminho sys/policies/acl que você tentou acessar:

path "sys/policies/acl" { capabilities = [""] }

24. Adicione o recurso. Como o Vault está tentando fazer uma chamada de API GET nesse caminho, é necessário adicionar o recurso read de novo. Além disso, a tentativa incluiu list=true no URL, então também é necessário adicionar esse recurso.

path "sys/policies/acl" { capabilities = ["read", "list"] }

Sua política atualizada deve ser semelhante a esta:

25. Clique em Save.

26. Volte para o Cloud Shell e execute este comando novamente:

vault policy list

O resultado deve ser semelhante a este:

default default-ceiling demo-policy root

27. Execute este comando para copiar os valores das políticas para um arquivo de texto:

vault policy list > policies.txt

28. Por fim, verifique novamente os recursos do token para o caminho sys/policies/acl:

vault token capabilities <your token> sys/policies/acl

Este resultado será exibido:

list, read

29. Execute este comando para copiar os valores das políticas para um arquivo de texto. Substitua <your token> pelo valor do seu token:

vault token capabilities <your token> sys/policies/acl > token_capabilities.txt

30. Execute estes comandos para copiar os arquivos de texto policies e token_capabilities para um bucket do Cloud Storage pré-criado para acompanhar seu progresso:

export PROJECT_ID=$(gcloud config get-value project) gcloud storage cp *.txt gs://$PROJECT_ID

Ao modificar a política associada ao usuário, as mudanças foram refletidas sem gerar um novo token. Isso acontece porque o conteúdo das políticas é analisado em tempo real sempre que o token é usado. Como resultado, se uma política for modificada, as regras modificadas serão aplicadas na próxima vez que um token com essa política anexada for usado para fazer uma chamada ao Vault.

Ótimo. Você criou uma política que concedeu acesso de leitura ao caminho sys/mounts e a associou a um usuário. Você também adicionou outra política para conceder acesso de leitura e listagem ao caminho sys/policies.

Clique em Verificar meu progresso para conferir o objetivo. Criar políticas

Tarefa 5: como gerenciar políticas

As políticas são criadas (escritas) no editor de sua preferência. Podem ser escritas em HCL ou JSON. A sintaxe está descrita em detalhes acima. Depois de salvas, as políticas precisam ser enviadas para o Vault antes de serem usadas.

Na seção anterior, você usou a interface para escrever e gerenciar uma política. Nesta seção, vamos abordar os comandos da CLI para gerenciar políticas.

• Execute este comando no Cloud Shell para fazer login no Vault com seu token "root":

vault login <your root token>

Como listar políticas

• Execute este comando para listar todas as políticas registradas no Vault:

vault read sys/policy

Este resultado deve ser exibido:

Key Value --- ----- keys [default demo-policy root] policies [default demo-policy root

Como criar políticas

As políticas podem ser criadas (enviadas) pela CLI, interface do usuário ou API. Na seção anterior, você usou a interface para criar o arquivo HCL.

Para criar uma nova política no Vault, use este comando:

vault policy write policy-name policy-file.hcl

1. Para testar, crie um arquivo de política básico com o este comando:

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } EOF

2. Verifique se o arquivo foi criado corretamente:

cat example-policy.hcl

3. Crie uma nova política chamada example-policy com o comando vault policy write:

vault policy write example-policy example-policy.hcl

Se a execução for concluída, este será o resultado:

Success! Uploaded policy: example-policy

Neste exemplo, o nome da política é "example-policy". Esse nome serve como um ponteiro ou link simbólico para as ACLs da política. Os tokens são anexados a políticas por nome, que são associadas ao conjunto de regras correspondente a esse nome.

Como atualizar políticas

É possível atualizar as políticas para alterar as permissões pela CLI ou API. Para atualizar uma política no Vault, siga as mesmas etapas da criação de uma política, mas use o nome de uma política atual.

1. Execute este comando para atualizar e substituir o arquivo da política para listar os métodos de autenticação:

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List auth methods path "sys/auth" { capabilities = ["read"] } EOF

2. Verifique se o arquivo foi criado corretamente:

cat example-policy.hcl

3. Atualize a política:

vault write sys/policy/example-policy policy=@example-policy.hcl

Ótimo. Você atualizou uma política usando a CLI.

4. Execute este comando para copiar o arquivo da política para um bucket do Cloud Storage pré-criado para monitorar seu progresso:

gcloud storage cp example-policy.hcl gs://$PROJECT_ID

Clique em Verificar meu progresso para conferir o objetivo. Criar e gerenciar políticas usando comandos da CLI

Como excluir políticas

As políticas podem ser excluídas pela CLI, API ou interface. Para excluir uma política, execute este comando:

vault delete sys/policy/policy-name

1. Vamos testar isso na prática. Execute este comando para excluir a política que você acabou de criar:

vault delete sys/policy/example-policy

Se a operação for bem-sucedida, o resultado será este:

Success! Data deleted (if it existed) at: sys/policy/example-policy

2. Liste as políticas com este comando:

vault policy list

Este resultado deve ser exibido:

default default-ceiling demo-policy root

Ótimo. Você excluiu a example-policy.

Observação: essa operação é idempotente. O Vault não vai retornar um erro ao excluir uma política que não existe.

Tarefa 6: como associar políticas

O Vault associa de forma automática um conjunto de políticas a um token com base em uma autorização. Essa configuração varia significativamente entre os back-ends de autenticação. Para simplificar, este exemplo usa o método de autenticação "userpass" integrado do Vault.

1. Execute este comando para criar o usuário firstname-lastname no Vault com uma lista de políticas associadas:

vault write auth/userpass/users/firstname-lastname \ password="s3cr3t!" \ policies="default, demo-policy" Success! Data written to: auth/userpass/users/firstname-lastname

Isso cria uma associação de autenticação para a política. Assim, quando o usuário se autenticar no Vault, receberá um token com a lista de políticas anexadas.

2. Execute este comando para se autenticar com o Vault:

vault login -method="userpass" username="firstname-lastname" password="s3cr3t!"

Este resultado deve ser exibido:

Key Value --- ----- token s.XnRsinhsokVUiN7XbsnyCOEC token_accessor JFErk5Rgb7vtW47CJjY2OCsF token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username firstname-lastname

Como as informações fornecidas estão corretas, o Vault vai gerar um token, atribuir a lista de políticas configuradas a ele e retorná-lo ao usuário autenticado.

Tokens

Os tokens têm dois conjuntos de políticas: as políticas de identidade, determinadas com base na entidade e nos grupos dela, e as políticas de token, definidas pelo método de login ou fornecidas na criação explícita de tokens pela API. Quanto às políticas de token exclusivamente, as políticas de identidade não podem ser controladas, exceto pela alteração das entidades, grupos e associações.

1. Faça login novamente no Vault com seu token "root":

vault login <your root token>

2. Os tokens são associados às políticas ao serem criados. Execute este comando para criar um token com as políticas dev-readonly e logs:

vault token create -policy=dev-readonly -policy=logs

Este resultado deve ser exibido:

Key Value --- ----- token s.gKRV6vzFmpdJ9iwvPfzNjAuI token_accessor S4jfdYvy8jQP7GGDa947CBlT token_duration 768h token_renewable true token_policies ["default" "dev-readonly" "logs"] identity_policies [] policies ["default" "dev-readonly" "logs"] Observação: ignore os avisos de que as políticas não existem, porque elas ainda não foram criadas.

Normalmente, só é possível especificar políticas que estejam presentes nas políticas do token pai do novo token. No entanto, os usuários raiz podem atribuir qualquer política.

Não é possível modificar as políticas associadas a um token depois de emiti-lo. O token precisa ser revogado e um novo token precisa ser adquirido para receber um novo conjunto de políticas.

No entanto, o conteúdo das políticas é analisado em tempo real sempre que o token é usado. Como resultado, se uma política for modificada, as regras modificadas serão aplicadas na próxima vez que um token com essa política anexada for usado para fazer uma chamada ao Vault.

Tarefa 7: políticas para Secrets

Nesta seção, você vai criar políticas do Vault para conceder aos usuários diferentes níveis de acesso e testá-las.

• No Cloud Shell, crie alguns usuários com políticas diferentes:

vault write auth/userpass/users/admin \ password="admin123" \ policies="admin" vault write auth/userpass/users/app-dev \ password="appdev123" \ policies="appdev" vault write auth/userpass/users/security \ password="security123" \ policies="security"

Depois de criar alguns usuários, crie as políticas associadas a eles. Para começar, a política admin deve ter acesso total a todos os Secrets do Vault.

Criar a política "admin"

Para este laboratório, um usuário admin precisa:

• Ler a verificação de integridade do sistema
• Criar e gerenciar políticas de ACL de forma ampla no Vault
• Ativar e gerenciar métodos de autenticação em todo o Vault
• Gerenciar o mecanismo de Secrets de chave-valor ativado no caminho secret/

1. Acesse ACL policies no painel esquerdo da interface do Vault. As políticas default, default-ceiling, demo-policy e root serão exibidas.

2. Clique em Create ACL policy.

3. Defina admin como o nome da política.

4. Em Policy rules, selecione Code editor e adicione este código de política:

# Read system health check path "sys/health" { capabilities = ["read", "sudo"] } # Create and manage ACL policies broadly across Vault # List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Enable and manage authentication methods broadly across Vault # Manage auth methods broadly across Vault path "auth/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, update, and delete auth methods path "sys/auth/*" { capabilities = ["create", "update", "delete", "sudo"] } # List auth methods path "sys/auth" { capabilities = ["read"] } # Enable and manage the key/value secrets engine at `secret/` path # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

Sua política deve ser semelhante a esta:

5. Clique em Create policy.

Criar a política "appdev"

Para este laboratório, um usuário appdev precisa:

• Criar, ler e atualizar mecanismos de Secrets
• Gerenciar o mecanismo de Secrets de chave-valor ativado no caminho secret/appdev/

1. Volte para a página ACL Policies.

2. Clique em Create ACL policy.

3. Defina appdev como o nome da política.

4. Em Policy rules, selecione Code editor e adicione este código de política:

# List, create, update, and delete key/value secrets path "secret/+/appdev/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, read, and update secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

5. Clique em Create policy.

Criar a política de segurança

Para os fins laboratório, um usuário de segurança precisa:

• Criar e gerenciar políticas de ACL de forma ampla no Vault
• Gerenciar mecanismos de Secrets
• Gerenciar o mecanismo de Secrets de chave-valor ativado no caminho secret/
• Não ter acesso de leitura ou listagem de Secrets no caminho secret/admin

1. Volte para a página ACL Policies.

2. Clique em Create ACL policy.

3. Defina security como o nome da política.

4. Em Policy rules, selecione Code editor e adicione este código de política:

# List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Deny access to secret/admin path "secret/data/admin" { capabilities = ["deny"] } path "secret/data/admin/*" { capabilities = ["deny"] } # Deny list access to secret/admin path "secret/metadata/admin" { capabilities = ["deny"] } path "secret/metadata/admin/*" { capabilities = ["deny"] }

5. Clique em Create policy.

Criar Secrets

Depois de criar as diferentes políticas, crie alguns Secrets.

1. Volte para o Cloud Shell e execute estes comandos para criar alguns Secrets no caminho secret/security:

vault kv put secret/security/first username=password vault kv put secret/security/second username=password

2. Crie alguns secrets no caminho secret/appdev:

vault kv put secret/appdev/first username=password vault kv put secret/appdev/beta-app/second username=password

3. Crie alguns secrets no caminho secret/admin:

vault kv put secret/admin/first admin=password vault kv put secret/admin/supersecret/second admin=password

Verificar a segurança para "appdev"

Depois de criar os Secrets, verifique se as políticas estão sendo aplicadas. Faça login como o usuário app-dev e confira o que você pode acessar.

1. Execute este comando para fazer login como usuário app-dev:

vault login -method="userpass" username="app-dev" password="appdev123"

2. Tente buscar o Secret appdev/first:

vault kv get secret/appdev/first

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. Busque o Secret localizado em secret/appdev/beta-app/second:

vault kv get secret/appdev/beta-app/second

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Crie um novo Secret:

vault kv put secret/appdev/appcreds credentials=creds123

5. Destrua o Secret:

vault kv destroy -versions=1 secret/appdev/appcreds

6. Tente acessar um Secret de secret/security:

vault kv get secret/security/first

Este erro será exibido:

Error reading secret/data/security/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/security/first Code: 403. Errors: * 1 error occurred: * permission denied

7. Tente listar todos os Secrets em secret/:

vault kv list secret/

Um erro será exibido novamente:

Error listing secret/metadata: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata?list=true Code: 403. Errors: * 1 error occurred: * permission denied

Ótimo. Você buscou e criou Secrets no caminho secret/appdev e verificou que não é possível acessá-los fora dele.

Verificar a política de segurança

1. Execute este comando para fazer login como usuário security:

vault login -method="userpass" username="security" password="security123"

2. Tente buscar o Secret security/first:

vault kv get secret/security/first

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. Busque o Secret localizado em secret/security/second:

vault kv get secret/security/second

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Crie um novo Secret em secret/security/supersecure:

vault kv put secret/security/supersecure/bigsecret secret=idk

5. Destrua o Secret:

vault kv destroy -versions=1 secret/security/supersecure/bigsecret

6. Tente ler um Secret de secret/appdev:

vault kv get secret/appdev/first

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. Tente listar todos os Secrets em secret/:

vault kv list secret/

Este resultado deve ser exibido:

Keys ---- admin/ appdev/ security/

8. Ative um novo mecanismo de Secrets:

vault secrets enable -path=supersecret kv Success! Enabled the kv secrets engine at: supersecret/

9. Tente acessar o Secret secret/admin/first:

vault kv get secret/admin/first

Este erro será exibido:

Error reading secret/data/admin/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/admin/first Code: 403. Errors: * 1 error occurred: * permission denied

10. Tente listar os Secrets em secret/admin:

vault kv list secret/admin

Um erro será exibido novamente:

Error listing secret/metadata/admin: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata/admin?list=true Code: 403. Errors: * 1 error occurred: * permission denied

Ótimo. Você pode buscar e criar Secrets no caminho secret/ e ativar um mecanismo de Secrets. Também teve o acesso negado ao caminho secret/admin, conforme especificado na política.

Verificar a política para "admin"

1. Execute este comando para fazer login como usuário admin:

vault login -method="userpass" username="admin" password="admin123"

2. Tente buscar o Secret admin/first:

vault kv get secret/admin/first

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:18.521925218Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ==== Data ==== Key Value --- ----- admin password

3. Busque um Secret localizado em secret/security/first:

vault kv get secret/security/first

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Crie um novo Secret:

vault kv put secret/webserver/credentials web=awesome

5. Destrua o Secret:

vault kv destroy -versions=1 secret/webserver/credentials

6. Tente acessar Secrets de secret/appdev:

vault kv get secret/appdev/first

Este resultado deve ser exibido:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. Tente listar todos os Secrets em secret/appdev:

vault kv list secret/appdev/

Este resultado deve ser exibido:

Keys ---- appcreds beta-app/ first

8. Liste todas as políticas:

vault policy list

Este resultado deve ser exibido:

admin appdev default default-ceiling demo-policy security root

9. Execute este comando para copiar os valores das políticas em um arquivo de texto e fazer upload dele no bucket do Cloud Storage:

vault policy list > policies-update.txt gcloud storage cp policies-update.txt gs://$PROJECT_ID

10. Ative o método de autenticação gcp:

vault auth enable gcp

11. Por fim, liste os métodos de autenticação ativados:

vault auth list Path Type Accessor Description ---- ---- -------- ----------- gcp/ gcp auth_gcp_faa3d15f n/a token/ token auth_token_066c5ebd token based credentials userpass/ userpass auth_userpass_929fe9bd n/a

Ótimo, você confirmou que tem os privilégios de admin associados à política que escreveu.

Clique em Verificar meu progresso para conferir o objetivo. Políticas para Secrets

Caminhos

Conforme mostrado no código da política fornecido para o usuário security, alguns tópicos novos foram apresentados: data/ e metadata/.

O endpoint do caminho metadata/ retorna uma lista de nomes de chaves no local especificado. Os valores em si não podem ser acessados com esse comando. As versões de gravação e leitura usam o prefixo data/. Para listar, ler e destruir, os caminhos são:

• Versões de gravação e leitura: data/
• Chaves de listagem: metadata/
• Versões de leitura: metadata/
• Destruir versões do Secret: destroy/
• Destruir todas as versões de metadados de uma chave: metadata/

Por exemplo, para negar o acesso a um Secret em secret/example, formate o caminho com data/ da seguinte forma:

path "secret/data/example" { capabilities = ["deny"] }

Para negar o acesso de listagem a secret/examples, formate com metadata/ da seguinte forma:

path "secret/metadata/examples/*" { capabilities = ["deny"] }

Tarefa 8: controle granular

Além do conjunto comum de recursos, o Vault oferece um controle mais granular das permissões em um determinado caminho. Os recursos associados a um caminho têm precedência sobre as permissões dos parâmetros.

Restrições de parâmetros

No Vault, os dados são representados como pares key=value. Como opção, as políticas do Vault podem restringir ainda mais os caminhos com base nas chaves e nos dados dessas chaves ao avaliar as permissões de um caminho. As opções de controle mais detalhado são:

• required_parameters: uma lista de parâmetros que precisam ser especificados.
• allowed_parameters: uma lista de chaves e valores permitidos no caminho especificado.
• denied_parameters: nega uma lista de parâmetros e valores. Os valores especificados aqui têm precedência sobre allowed_parameters

Para mais informações, confira a documentação sobre o controle detalhado (em inglês).

Parabéns.

As políticas são uma parte importante do Vault. Embora usar o token "root" seja a maneira mais fácil de começar, se você precisar restringir o acesso ao Vault rapidamente, o sistema de políticas permite fazer isso.

A sintaxe e a função das políticas são fáceis de entender e usar, e como todos os métodos de autenticação precisam ser associados ao sistema de políticas central, você só precisa aprender esse sistema.

Neste laboratório, você criou e gerenciou políticas, associou-as a usuários e tokens e verificou as permissões delas.

Próximas etapas / Saiba mais

Confira mais informações sobre o Vault nestes tópicos:

• Tutoriais de introdução ao Vault (em inglês)
• Documentação do Vault (em inglês)
• Documentação da política do Vault (em inglês)
• Tutorial sobre políticas do Vault(em inglês)

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 4 de junho de 2026

Laboratório testado em 4 de junho de 2026

Copyright 2026 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.