Новые токены не разрешают доступ к политике - PullRequest
Новая
       18

Новые токены не разрешают доступ к политике

1 голос
/ 17 апреля 2019

Настроили контейнер докера Hashicorp Vault, но, похоже, не удается получить учетные данные базы данных при использовании сгенерированного токена, а не root. 

error occurred: permission denied

Шаги для воссоздания:

Я создалпоследний контейнер, получил корневой токен и использовал его для аутентификации.

Запустил следующие команды: 

export VAULT_ADDR='http://127.0.0.1:8200'
vault secrets enable database
vault auth enable approle
vault write sys/policy/test policy='path "database/roles/" {capabilities = ["create", "read", "update", "delete", "list"]} path "auth/approle/login" { capabilities = [ "create", "read" ]} path "database/creds/" {capabilities = ["create", "read", "update", "delete", "list"]} path "secret/dbcreds" {capabilities = ["create", "update", "read"]} path "sys/mounts/" {capabilities = [ "create", "read", "update", "delete", "list" ]} path "database/" { capabilities = [ "create", "read", "update", "delete", "list" ]}'
vault write database/config/mssql plugin_name="mssql-database-plugin" root_rotation_statements="ALTER LOGIN [{{username}}] WITH PASSWORD = '{{password}}'" connection_url="sqlserver://{{username}}:{{password}}@sql:1433" allowed_roles="*,test" username="***MY_USER***" password="***MY_PASS***"
vault write database/roles/Tenant_1 db_name=mssql creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';USE [Tenant_1];CREATE USER [{{name}}] FOR LOGIN [{{name}}];ALTER ROLE [db_owner] ADD MEMBER [{{name}}];" default_ttl="1h" max_ttl="24h"
vault write auth/approle/role/test secret_id_ttl=0 token_num_uses=0 token_ttl=20m token_max_ttl=30m secret_id_num_uses=0 policies="default, test"
vault read auth/approle/role/test/role-id
vault write -f auth/approle/role/test/secret-id
vault write auth/approle/login role_id=***role_id*** secret_id=***secret_id***
vault secrets enable -version=2 kv

Я также попытался заменить 'vault write' на 'vault kv put', иполучил успех для всех команд.

Поэтому я вызываю GET http://127.0.0.1:8200/v1/database/creds/Tenant_1,, используя заголовок: 

X-Vault-Token
**Root-Token**

Это работает.

Если я вызываю POST http://127.0.0.1:8200/v1/auth/approle/login с действительной ролью / секретным идентификатором, я вернул токен успешно.Однако, если я попытаюсь использовать этот токен вместо Root в вызове GET, он выдаст отказано в разрешении.

Просматривая конфигурацию политики, мне кажется, что / database / creds является частью политики.

Если я сделаю поиск токена на сгенерированном: 

Key                 Value
---                 -----
accessor            PNe8WQiXnZvlFNEJekXO2es4
creation_time       1555517775
creation_ttl        20m
display_name        approle
entity_id           acc7558b-02b1-328d-4705-74f00ab9524b
expire_time         2019-04-17T16:36:15.6815637Z
explicit_max_ttl    0s
id                  s.iGkfsCUS6JX58SiDl8pfFN2K
issue_time          2019-04-17T16:16:15.6815627Z
meta                map[role_name:test]
num_uses            0
orphan              true
path                auth/approle/login
policies            [default test]
renewable           true
ttl                 16m35s
type                service

Мне хорошо смотрится??

Есть идеи?

1 Ответ

1 голос
/ 18 апреля 2019

Хорошо, это потратило много часов, но есть решение для всех, у кого есть похожие проблемы.

Мои политики отсутствовали / * с конца, поэтому, хотя токен был действительным, у него не было разрешения на доступ к этим учетным данным.

...