Модуль доступен только в Deckhouse Enterprise Edition.

Общее описание

Deckhouse Stronghold - это программное обеспечение для управления доступом и защиты секретов в IT-инфраструктуре компании.

Deckhouse Stronghold предназначен для управления секретами, их хранения и распространения в безопасной и управляемой среде. Он позволяет организациям безопасно хранить и получать доступ к конфиденциальной информации, такой как пароли, ключи API, сертификаты и другие секреты, необходимые для работы приложений и сервисов. Deckhouse Stronghold предоставляет централизованное управление и контроль над этими секретами, обеспечивая надежное и безопасное хранение, а также возможность аудита и мониторинга.

Основные функциональные характеристики Deckhouse Stronghold включают:

Название функции Результат
Централизованное хранение секретов: Deckhouse Stronghold управляет всеми секретами в едином месте, обеспечивая их централизованное хранение и управление. Повышение эффективности и безопасности управления секретами, а также упрощение процесса доступа к ним для пользователей.
Контроль доступа: Deckhouse Stronghold предоставляет возможность настройки и управления доступом к секретам на основе ролей, политик и ACL (списков контроля доступа). Это позволяет определить, кто имеет доступ к каким секретам и какие операции с ними могут выполняться. Настроен контроль доступа к секретам, основанный на ролях, политиках и списках контроля доступа.
Шифрование данных: Все секреты, хранящиеся в Deckhouse Stronghold, шифруются на стороне клиента с использованием криптостойкого шифрования. Это гарантирует безопасность данных и предотвращает несанкционированный доступ к ним. Данные, хранящиеся в Deckhouse Stronghold, шифруются на стороне клиента.
Журналирование и мониторинг: Deckhouse Stronghold предоставляет возможности для аудита, мониторинга и журналирования всех операций с секретами. Это позволяет отслеживать, кто, когда и какие действия выполнял с секретами. Производится мониторинг и логирование приложений, работающих на кластере, в соответствии с настройками пользователя с ролью администратор.
Интеграция с другими инструментами: Deckhouse Stronghold может интегрироваться с различными инструментами и платформами, такими как контейнеры, облачные провайдеры, системы управления исходным кодом и т. д. Это позволяет использовать Deckhouse Stronghold в составе существующей инфраструктуры. Расширение функциональности и возможность работать вместе с другими программными продуктами.

Deckhouse Stronghold обеспечивает безопасное управление секретами в IT-инфраструктуре компании для защиты от несанкционированного доступа и минимизации рисков утечек конфиденциальной информации.

Модули Deckhouse Stronghold

  1. KV secrets engine
  2. JWT/OIDC auth method
  3. Token auth method
  4. Userpass auth method
  5. Identity secrets engine
  6. Cubbyhole secrets engine

Инструмент KV secrets

При работе бэкенда kv secrets в неверсионном режиме сохраняется только последнее записанное значение ключа. Преимуществом использования неверсионного kv является уменьшение размера хранилища для каждого ключа, так как не сохраняются дополнительные метаданные и история изменений. Кроме того, операции запроса к бэкенду, настроенному таким образом, являются более производительными, так как для каждого конкретного запроса требуется меньше обращений к хранилищу данных и не возникает блокировки при изменении значения ключа.

KV версия 1

При использовании бэкенда Key-Value хранилища в режиме без поддержки версионирования, сохраняется только последнее обновленное значение ключа. Основным преимуществом использования данного режима является уменьшение занимаемого пространства на хранилище для каждого ключа, так как не сохраняются дополнительные метаданные и история изменений. Кроме того, операции запроса к бэкенду, настроенному таким образом, являются более производительными, так как для каждого конкретного запроса требуется меньше обращений к хранилищу данных и не возникает блокировки при изменении значения ключа.

KV версия 2

При использовании версии 2 бэкенда kv ключ может сохранять настраиваемое количество версий. По умолчанию это 10 версий. Метаданные и данные старых версий могут быть извлечены. Кроме того, для предотвращения случайной перезаписи данных можно использовать операции Check-and-Set.

При удалении версии данные, лежащие в ее основе, не удаляются, а помечаются как удаленные. Удаленные версии могут быть отменены. Для окончательного удаления данных версии можно использовать команду destroy или конечную точку API. Кроме того, все версии и метаданные для ключа могут быть удалены командой delete по метаданным или конечной точкой API. На каждую из этих операций можно наложить различные ACL, ограничивающие права на мягкое удаление, удаление без удаления или полное удаление данных.

Метод аутентификации JWT/OIDC

Метод jwt auth может быть использован для аутентификации в Deckhouse Stronghold с помощью OIDC или путем предоставления JWT.

Метод OIDC позволяет выполнять аутентификацию через настроенный провайдер OIDC с помощью веб-браузера пользователя. Этот метод может быть инициирован из пользовательского интерфейса Deckhouse Stronghold или из командной строки. В качестве альтернативы может быть предоставлен непосредственно JWT. JWT криптографически проверяется с помощью локально предоставленных ключей, либо, если настроен, для получения соответствующих ключей может быть использован сервис OIDC Discovery. Выбор метода настраивается для каждой роли.

Оба метода позволяют дополнительно обрабатывать данные утверждений в JWT. В документе рассмотрены концепции, общие для обоих методов, а также примеры использования OIDC и JWT.

Аутентификация в OIDC

В данном разделе рассматривается настройка и использование ролей OIDC. Предполагается базовое знакомство с концепциями OIDC. Поток Authorization Code использует расширение Proof Key for Code Exchange (PKCE).

Deckhouse Stronghold включает два встроенных потока авторизации OIDC: пользовательский интерфейс Deckhouse Stronghold UI и CLI с использованием логина vault.

Перенаправление URI

Важной частью конфигурации ролей OIDC является правильная настройка URI перенаправления. Это должно быть сделано как в Deckhouse Stronghold, так и в провайдере OIDC, причем эти настройки должны совпадать. URI перенаправления задаются для роли с помощью параметра allowed_redirect_uris. Для настройки потоков Deckhouse Stronghold UI и CLI существуют различные URI перенаправления, поэтому в зависимости от установки необходимо настроить один или оба.

CLI

Если планируется поддержка аутентификации через vault login -method=oidc, необходимо задать URI перенаправления на localhost. Обычно это может быть: http://localhost:8250/oidc/callback. При необходимости при входе в систему через CLI можно указать другой хост и/или порт прослушивания, при этом URI с этим хостом/портом должен совпадать с одним из настроенных перенаправляемых URI. Эти же URI “localhost” должны быть добавлены и в провайдер.

Deckhouse Stronghold UI

Для входа в систему через Deckhouse Stronghold сам UI не требует настройки и конфигурируется автоматически при включении Deckhouse Stronghold

Вход в систему OIDC (Deckhouse Stronghold UI)

Выберите метод входа в систему “OIDC”.

При необходимости введите имя роли.

Нажмите кнопку “Войти с помощью провайдера OIDC” и завершите аутентификацию с помощью настроенного провайдера.

Вход в систему OIDC (CLI)

Для входа в систему CLI по умолчанию используется путь /oidc_deckhouse. Если данный метод аутентификации был включен по другому пути, укажите в CLI путь -path=/my-path.

vault login -method=oidc -path=oidc_deckhouse role=test
Complete the login via your OIDC provider. Launching browser to:
https://myco.auth0.com/authorize?redirect_uri=http%3A%2F%2Flocalhost%3A8400%2Foidc%2Fcallback&client_id=r3qXc2bix9eF...

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

Автоматический запуск браузера по умолчанию на URL переключается при помощи skip_browser (по умолчанию: “false”) при входе в систему.

Слушатель обратного вызова может быть настроен с помощью следующих необязательных параметров. Обычно их установка не требуется:

  • mount (по умолчанию “oidc”)
  • listenaddress (по умолчанию “localhost”)
  • port (по умолчанию 8250)
  • callbackhost (по умолчанию “localhost”)
  • callbackmethod (по умолчанию “http”)
  • callbackport (по умолчанию - это значение, заданное для порта). Это значение используется в параметре redirect_uri, тогда как port - это порт сервера localhost, который принимает запросы. В некоторых случаях эти два параметра могут различаться.

Конфигурация провайдера OIDC

Способ аутентификации OIDC успешно протестирован с рядом провайдеров. Полное руководство по настройке приложений OAuth/OIDC не входит в документацию Deckhouse Stronghold.

Устранение неполадок в конфигурации OIDC

Некоторые советы по настройке OIDC представлены ниже:

  • Если параметр роли (например, bound_claims) требует значения карты (map), его нельзя установить отдельно с помощью Deckhouse Stronghold CLI. В таких случаях запишите конфигурацию в виде одного JSON-объекта:

    vault write auth/oidc/role/demo -<<EOF
{
"user_claim": "sub",
"bound_audiences": "abc123",
"role_type": "oidc",
"policies": "demo",
"ttl": "1h",
"bound_claims": { "groups": ["mygroup/mysubgroup"] }
}
EOF

  • Проследите за выводом журнала Deckhouse Stronghold, в котором содержится важная информация о сбоях проверки OIDC.

  • Убедитесь, что URI перенаправления корректны в Deckhouse Stronghold и на провайдере. Они должны точно совпадать. Проверьте: http/https, 127.0.0.1/localhost, номера портов, наличие слэшей в конце.

  • Единственной конфигурацией утверждения, которая требуется для роли, является user_claim. Когда станет известно, что аутентификация работает, добавьте дополнительные привязки утверждений и копирование метаданных.

  • bound_audiences не является обязательным для ролей OIDC и обычно не требуется. Идентификаторы клиентов OIDC используют client_id для определения аудитории, и проверка OIDC предполагает это.

  • Уточните у провайдера диапазоны для получения необходимой информации. Часто требуется запрашивать диапазоны “профиль” и “группы”, которые можно добавить, установив для роли значение oidc_scopes="profile,groups".

  • Если в журналах появляются ошибки, связанные с заявками, внимательно изучите документацию поставщика, чтобы понять, как он называет и структурирует заявки. В зависимости от провайдера, сконструируйте простой запрос curl implicit grant для получения JWT, который можно просмотреть.

Пример декодирования JWT (в примере он расположен в поле access_token JSON-ответа) представлен ниже:

cat jwt.json | jq -r .access_token | cut -d. -f2 | base64 -D
  • В Deckhouse Stronghold доступна ролевая опция verbose_oidc_logging, которая будет записывать полученный OIDC-токен в журналы сервера, если включено ведение журнала на уровне отладки. Это может быть полезно при отладке настройки провайдера и проверке того, что полученные претензии соответствуют ожиданиям. Поскольку данные утверждений записываются в журнал дословно и могут содержать конфиденциальную информацию, эту опцию не следует использовать в производстве.

Аутентификация по JWT

Способ аутентификации для ролей типа “jwt” проще, чем в OIDC, поскольку Deckhouse Stronghold требуется только проверить предоставленный JWT.

Проверка JWT

Подписи JWT будут проверяться по открытым ключам эмитента. Этот процесс может осуществляться тремя способами, но для одного бэкенда может быть настроен один метод:

  • Статические ключи. Набор открытых ключей хранится в конфигурации бэкенда.
  • JWKS. Настраивается URL-адрес JSON Web Key Set (JWKS) (и дополнительная цепочка сертификатов). Ключи извлекаются из конечной точки при аутентификации.
  • OIDC Discovery. Настраивается URL-адрес OIDC Discovery (и необязательная цепочка сертификатов). Ключи извлекаются из URL при аутентификации. Когда используются OIDC Discovery, то применяются критерии проверки OIDC (например, iss, aud и т.д.).

Если необходимо использовать несколько методов, можно установить и сконфигурировать другой экземпляр бэкенда.

Аутентификация JWT через CLI

vault write auth/<path-to-jwt-backend>/login role=demo jwt=...

Путь по умолчанию для бэкенда аутентификации JWT - /jwt, поэтому если вы используете бэкенд по умолчанию, то команда будет выглядеть так:

vault write auth/jwt/login role=demo jwt=...

Если бэкенд JWT auth использует другой путь, используйте его.

Аутентификация JWT через API

По умолчанию используется конечная точка auth/jwt/login. Если этот метод аутентификации был включен по другому пути, используйте это значение вместо jwt, как представлено на примере ниже:

curl \
  --request POST \
  --data '{"jwt": "your_jwt", "role": "demo"}' \
  http://127.0.0.1:8200/v1/auth/jwt/login

В ответе, который представлен ниже, будет содержаться токен по адресу auth.client_token:

{
  "auth": {
    "client_token": "38fe9691-e623-7238-f618-c94d4e7bc674",
    "accessor": "78e87a38-84ed-2692-538f-ca8b9f400ab3",
    "policies": ["default"],
    "metadata": {
      "role": "demo"
    },
    "lease_duration": 2764800,
    "renewable": true
  }
}

Конфигурация

Перед тем как проходить аутентификацию, необходимо настроить методы аутентификации. Эти шаги выполняются оператором или средством управления конфигурацией.

  1. Включите метод аутентификации JWT. Можно выбрать имя jwt или oidc. Бэкэнд будет монтироваться по выбранному имени.

    vault auth enable jwt
or
vault auth enable oidc

  2. Для настройки Deckhouse Stronghold используйте конечную точку /config. Для поддержки ролей JWT необходимо наличие локальных ключей, URL JWKS или URL OIDC Discovery. Для ролей OIDC необходимо наличие OIDC Discovery URL, OIDC Client ID и OIDC Client Secret.

    vault write auth/jwt/config \
   oidc_discovery_url="https://myco.auth0.com/" \
   oidc_client_id="m5i8bj3iofytj" \
   oidc_client_secret="f4ubv72nfiu23hnsj" \
   default_role="demo"

    Если необходимо выполнить проверку JWT с помощью валидации JWT-токена, оставьте oidc_client_id и oidc_client_secret пустыми.

    vault write auth/jwt/config \
   oidc_discovery_url="https://MYDOMAIN.eu.auth0.com/" \
   oidc_client_id="" \
   oidc_client_secret=""

  3. Создайте именованную роль:

    vault write auth/jwt/role/demo \
   allowed_redirect_uris="http://localhost:8250/oidc/callback" \
   bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
   bound_audiences="https://vault.plugin.auth.jwt.test" \
   user_claim="https://vault/user" \
   groups_claim="https://vault/groups" \
   policies=webapps \
   ttl=1h

    Эта роль авторизует JWT с заданными утверждениями subject и audience, задает политику webapps и использует заданные утверждения user/groups для настройки псевдонимов Identity.

Связанные параметры

После того как JWT подтвержден, как правильно подписанный, без истекшего срока хранения, поток авторизации проверяет соответствие всех настроенных “связанных” параметров. В некоторых случаях существуют специальные параметры, например, bound_subject, которые должны совпадать с параметром sub в JWT. Роль также может настраиваться на проверку произвольных утверждений с помощью карты (map) bound_claims. Карта содержит набор утверждений и их необходимых значений. Например, параметр bound_claims может иметь следующее значение:

{
   "division": "Europe",
   "department": "Engineering"
}

Будут авторизованы только JWT, содержащие утверждения division и department, и соответствующие им значения Europe и Engineering. Если значение представляет собой список, то утверждение должно соответствовать одному из элементов списка. Чтобы ограничить авторизацию набором адресов электронной почты используйте следующее:

{
   "email": ["fred@example.com", "julie@example.com"]
}

Связанные формулы могут быть опционально сконфигурированы с помощью globes. Globe - это определение шаблонов в тексте, которые могут быть заменены при выполнении операции. Например, если у пользователя есть glob *.conf, то при выполнении операции с этим glob все файлы с расширением .conf будут обработаны. Это полезно при автоматизации процессов, связанных с обработкой файлов.

Утверждения как метаданные

Данные из утверждений могут быть скопированы в результирующие метаданные токена аутентификации и псевдонима (alias) с помощью настройки claim_mappings. Этот параметр роли представляет собой карту элементов для копирования. Элементы карты имеют вид: “<JWT claim>”:"<metadata key>". Предположим, что параметр claim_mappings имеет значение:

{
   "division": "organization",
   "department": "department"
}

Это указывает, что значение JWT-требования division должно копироваться в ключ метаданных organization. Значение утверждения JWT department также копируется в метаданные, но при этом сохраняется имя ключа. Если утверждение сконфигурировано в claim_mappings, то должно существовать и в JWT, иначе аутентификация завершится неудачей.

Примечание: имя ключа метаданных “role” зарезервировано и не может быть использовано для сопоставления утверждений.

Спецификации утверждений и JSON-указатель

Некоторые параметры (например, bound_claims, groups_claim, claim_mappings, user_claim) используются для указания на данные в JWT. Если нужный ключ находится на верхнем уровне JWT, то имя ключа может быть указано напрямую. Если же он вложен на более низком уровне, то можно использовать JSON-указатель.

Предположим, что необходимо сослаться на следующие JSON-данные:

{
   "division": "North America",
   "groups": {
      "primary": "Engineering",
      "secondary": "Software"
   }
}

Параметр division будет ссылаться на North America, поскольку это ключ верхнего уровня. Параметр /groups/primary использует синтаксис JSON Pointer для ссылки на Engineering на более низком уровне. В качестве селектора может быть использован любой допустимый указатель JSON Pointer.

Token auth method

Метод аутентификации по токену является встроенным и автоматически доступен по адресу /auth/token. Он позволяет пользователям проходить аутентификацию с помощью токена, а также создавать новые токены, отзывать секреты по токену и т.д.

Когда любой другой метод аутентификации возвращает идентификатор, ядро Deckhouse Stronghold вызывает метод token для создания нового уникального токена для этого идентификатора.

Хранилище токенов также может быть использовано в обход любого другого метода аутентификации: вы можете создавать токены напрямую, а также выполнять различные другие операции с токенами, такие как обновление и отзыв.

Аутентификация

Через CLI

В этом примере пользователь выполняет вход в систему vault, используя токен:

vault login token=<token>

В следующем примере пользователь выполняет вход в систему vault с использованием метода аутентификации userpass. Пользователь вводит свои учетные данные в формате username=значение и password=значение.

vault login -method=userpass \
   username=mitchellh \
   password=foo

Через API

Токен задается непосредственно в виде заголовка для HTTP API. Заголовок должен иметь вид X-Vault-Token: <token> или Authorization: Bearer <token>.

curl \
   --request POST \
   --data '{"password": "foo"}' \
   http://127.0.0.1:8200/v1/auth/userpass/login/mitchellh

В ответе будет содержаться токен по адресу auth.client_token, как представлено ниже в примере:

{
   "lease_id": "",
   "renewable": false,
   "lease_duration": 0,
   "data": null,
   "auth": {
      "client_token": "c4f280f6-fdb2-18eb-89d3-589e2e834cdb",
      "policies": ["admins"],
      "metadata": {
         "username": "mitchellh"
      },
      "lease_duration": 0,
      "renewable": false
   }
}

Метод userpass auth

Метод авторизации userpass позволяет пользователям проходить аутентификацию в Deckhouse Stronghold с помощью комбинации имени пользователя и пароля.

Комбинации имени пользователя и пароля конфигурируются непосредственно в методе auth с помощью пути users/. Этот метод не может считывать имена пользователей и пароли из внешнего источника.

Все вводимые имена пользователей записываются в нижнем регистре, например, Mary и mary - это одна и та же запись.

Конфигурация

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

  1. Включите метод аутентификации userpass, как представлено ниже:

    vault auth enable userpass

    Это позволяет включить метод аутентификации userpass по адресу auth/userpass. Чтобы включить его по другому пути, используйте флаг -path, как представлено ниже:

    vault auth enable -path=<path> userpass

  2. Настройте метод на пользователей, которым разрешена аутентификация:

    vault write auth/<userpass:path>/users/mitchellh \
   password=foo \
   policies=admins

В результате создается новый пользователь mitchellh с паролем foo, который будет связан с политикой admins. Это единственная необходимая конфигурация.

Identity secrets engine

Механизм Identity - это решение для управления идентификацией в Deckhouse Stronghold. Внутри системы хранятся клиенты, которые распознаются Deckhouse Stronghold. Каждый клиент называется сущностью. Сущность может иметь несколько псевдонимов (aliases).

Например, один пользователь, имеющий учетные записи на GitHub и LDAP, может быть сопоставлен с одной сущностью в Deckhouse Stronghold, имеющей два псевдонима: один типа GitHub, другой типа LDAP. При успешной аутентификации клиента через любой из бэкендов (кроме бэкенда Token) Deckhouse Stronghold создает новую сущность и прикрепляет к ней новый псевдоним, если соответствующая сущность еще не существует. Идентификатор сущности будет привязан к аутентифицированному токену. При использовании таких токенов их идентификаторы сущностей регистрируются в журнале аудита, что позволяет проследить за действиями конкретных пользователей.

Хранилище идентификаторов позволяет операторам управлять сущностями в Deckhouse Stronghold. Можно создавать сущности и привязывать к ним псевдонимы с помощью ACL API. Для сущностей могут быть установлены политики, которые добавляют возможности токенам, привязанным к идентификаторам сущностей. Возможности, предоставляемые токенам через сущности, являются дополнением к существующим возможностям токена, а не заменой. Возможности токена, наследуемые от сущностей, вычисляются динамически во время запроса. Это обеспечивает гибкость в управлении доступом к уже выпущенным токенам.

ПРИМЕЧАНИЕ: Этот механизм секретов будет установлен по умолчанию. Этот механизм секретов нельзя отключить или переместить. Более подробный концептуальный обзор идентификации см. в документации по идентификации.

Cubbyhole secrets engine

Механизм секретов cubbyhole используется для хранения произвольных секретов в сконфигурированном физическом хранилище Vault, привязанном к токену. В cubbyholeпути распределены по токенам. Ни один токен не может получить доступ к cubbyhole другого токена. Когда срок действия токена истекает, его cubbyhole уничтожается.

Также в отличие от движка секретов kv, поскольку время жизни cubbyhole связано со временем жизни токена аутентификации, не существует понятия TTL или интервала обновления для значений, содержащихся в cubbyhole токене.

Запись в ключ в механизме секретов cubbyhole полностью заменит старое значение.

Настройка

Большинство секретных механизмов необходимо предварительно настроить, прежде чем они смогут выполнять свои функции. Эти шаги обычно выполняются оператором или инструментом управления конфигурацией.

Механизм секретов cubbyhole включен по умолчанию. Его нельзя отключить, переместить или включить несколько раз.

Использование

После того как механизм секретов настроен и у пользователя есть токен Vault с соответствующими правами, который может генерировать учетные данные. Механизм секретов cubbyhole позволяет записывать ключи с произвольными значениями

  1. Запись произвольных данных:

    $ vault write cubbyhole/my-secret my-value=s3cr3t

Success! Data written to: cubbyhole/my-secret

  2. Чтение произвольных данных:

    $ vault read cubbyhole/my-secret

Key         Value

---         -----

my-value    s3cr3t