Назад | Перейти на главную страницу

Hashicorp Vault - политика, ограничивающая один конкретный подузел на пути

У меня настроен сервер Hashicorp Vault, и все работает отлично, за исключением моих политик запрета.

У меня есть двухуровневая группировка для большинства секретов, поэтому они следуют структуре:

secret/client/environment/*

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

Основываясь на приведенных выше требованиях, я получил политику, которая выглядит так:

# Allow access to non client / environment secrets
path "secret/"
{
  capabilities = ["create", "read", "update", "list"]
}

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

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

# No access to restricted secrets
path "secret/+/+/restricted"
{
  capabilities = ["deny"]
}

path "secret/+/+/restricted/*"
{
  capabilities = ["deny"]
}

Если я создаю токен с помощью политики и использую этот токен в команде «Возможности токена хранилища», он возвращает то, что я ожидал:

$vault token capabilities $(cat token.txt) secret/client/environment/blah
create, list, read, update

$vault token capabilities $(cat token.txt) secret/client/environment/restricted
deny

$vault token capabilities $(cat token.txt) secret/client/environment/restricted/blah
deny

Проблема возникает, когда я вхожу в систему, используя этот токен, я могу не только перечислить содержимое ограниченного узла, но также получить подробную информацию о любом ключе в нем (на всех уровнях ниже). Это верно как через интерфейс командной строки, так и через веб-интерфейс.

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

Когда я вхожу в систему с использованием токена, он показывает правильную политику (а также политику по умолчанию, но по умолчанию нет разрешений на secret /).

secret / настроен как хранилище kv, поэтому я обращаюсь к ним через интерфейс командной строки, используя "vault kv list | get ..."

Есть ли еще один шаг, который я должен предпринять, чтобы «заставить» правила политики войти в систему?

Оказалось, что из-за того, что я использовал бэкэнд KV v2 для секретного хранилища, структуры политик немного отличаются.

В итоге мне пришлось указать секрет /метаданные/ для перечисления разрешений и секрета /данные/ для создания / обновления / чтения

например:

# Allow listing of all secret branches
path "secret/metadata/"
{
  capabilities = ["list"]
}
path "secret/metadata/+/"
{
  capabilities = ["list"]
}

path "secret/metadata/+/+/"
{
  capabilities = ["list"]
}

# Allow management of all keys under secret/<client>/<environment> structure
path "secret/data/+/+/+"
{
  capabilities = ["create", "read", "update"]
}

И вместо того, чтобы поставить "запретить" на ограниченный узел, единственным другим узлом на этом уровне (на данный момент) является "неограниченный" узел, поэтому я добавил:

path "secret/metadata/+/+/unrestricted/"
{
  capabilities = ["list"]
}

path "secret/data/+/+/unrestricted/*"
{
  capabilities = ["create", "read", "update"]
}

Поскольку политики Vault по умолчанию запрещены, это имело желаемый эффект.

Я нашел подробную информацию о настройке политики KV2 по адресу: https://www.vaultproject.io/docs/secrets/kv/kv-v2.html#acl-rules