пути шаблонов хранилища в политиках приводят к отказу в доступе - PullRequest
Новая
       10

пути шаблонов хранилища в политиках приводят к отказу в доступе

0 голосов
/ 12 февраля 2020

Я пытаюсь создать политику, которая позволяет пользователям получать доступ к части секретной иерархии на основе их имен пользователей. Вместо того, чтобы иметь разные политики для каждого пользователя, я хочу иметь одну шаблонную политику. Я думаю, что это должно работать, но я продолжаю получать ошибки, в которых отказано в разрешении. Если я удаляю шаблон и просто жестко кодирую имя пользователя в пути политики, секретный поиск работает просто отлично, поэтому не похоже, что это какая-то другая часть определения политики.

Это все с Vault 1.3.1, против dev-сервера, но проблема впервые возникла на не-dev-сервере, с аутентификацией GCP / GCE и секретами базы данных, поэтому, похоже, c не указывается ни для одной из этих вещей, либо .

Включите аутентификацию по имени пользователя и паролю и создайте пользователя, который указывает на новую политику (будет определено позже). 

$ vault auth enable userpass
Success! Enabled userpass auth method at: userpass/

$ vault write auth/userpass/users/duvall policies=default,p2 password=duvall
Success! Data written to: auth/userpass/users/duvall

Войдите в систему под этим пользователем и посмотрите на токен метаданные. 

$ vault login -method userpass username=duvall password=duvall

$ vault token lookup
Key                 Value
---                 -----
accessor            9ga3alRqZ6E3aSCEBNFWJY1X
creation_time       1581468214
creation_ttl        768h
display_name        userpass-duvall
entity_id           7513dc68-785b-d151-0efb-71315fc026dc
expire_time         2020-03-15T00:43:34.707416501Z
explicit_max_ttl    0s
id                  s.YZRQ3uclh2rg2H7gh3qH84P3
issue_time          2020-02-12T00:43:34.707423899Z
meta                map[username:duvall]
num_uses            0
orphan              true
path                auth/userpass/login/duvall
policies            [default p2]
renewable           true
ttl                 767h50m35s
type                service

Создайте вышеупомянутую политику с путем, основанным на ключе метаданных username. 

$ export VAULT_TOKEN=root

$ echo 'path "secret/data/role-secrets/{{identity.entity.metadata.username}}/*" {capabilities = ["read"]}' | vault policy write p2 -
Success! Uploaded policy: p2

Создайте секрет, соответствующий пути в политике. 

$ vault kv put secret/role-secrets/duvall/s1 foo=bar
Key              Value
---              -----
created_time     2020-02-12T00:44:36.509412834Z
deletion_time    n/a
destroyed        false
version          1

Как пользователь, чтение секрета приводит к сбою. 

$ export VAULT_TOKEN=s.YZRQ3uclh2rg2H7gh3qH84P3

$ vault kv get secret/role-secrets/duvall/s1
Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/internal/ui/mounts/secret/role-secrets/duvall/s1
Code: 403. Errors:

* preflight capability check returned 403, please ensure client's policies grant access to path "secret/role-secrets/duvall/s1/"

Переписать политику для удаления шаблонов. 

$ export VAULT_TOKEN=root

$ echo 'path "secret/data/role-secrets/duvall/*" {capabilities = ["read"]}' | vault policy write p2 -
Success! Uploaded policy: p2

На этот раз чтение секрета успешно.

* 1 025 *

Я не уверен, насколько это актуально, но ... добавление возможности списка метаданных в политику меняет ошибку чтения с «проверки возможности предварительной проверки» на более обычную «отказано в разрешении». 

$ echo 'path "secret/metadata/*" {capabilities = ["list"]}\npath "secret/data/role-secrets/{{identity.entity.metadata.username}}/*" {capabilities = ["read"]}' | VAULT_TOKEN=root vault policy write p2 -
Success! Uploaded policy: p2

$ vault kv get secret/role-secrets/duvall/s1
Error reading secret/data/role-secrets/duvall/s1: Error making API request.

URL: GET http://127.0.0.1:8200/v1/secret/data/role-secrets/duvall/s1
Code: 403. Errors:

* 1 error occurred:
        * permission denied
...