Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
UPDATE (8 июля, 2021): я обновил фрагмент кода default_role для работы с Vault 1.7.1.
Vault — это отличный инструмент, обеспечивающий безопасный и надежный способ хранения и распространения секретов, таких как ключи API, токены доступа и пароли. В данной статье главным образом сфокусируемся на процессах аутентификации и авторизации в Vault с помощью Google G-Suite OIDC и добавления групповых claim (заявлений о группах) в среде платформы Google Cloud.
В чем преимущество групповых claim?
Google G-Suite упрощает процессы управления для пользователя и отлично ладит с платформой Google Cloud. Групповой claim может использоваться для авторизации пользователя в Vault посредством маппинга связанной группы Google G-Suite c группой Vault. Таким образом к пользователю будет применена соответствующая политика Vault.
Предварительные настройки
Следуйте шагам из инструкции по конфигурации Vault OIDC. Ее можно свести к следующим пунктам:
- Создание учетных данные Google OAuth для получения client_id и client_secret
- Учетная запись G Suite c ролью суперадминистратора для предоставления доступа к API-интерфейсу делегирования для всего домена
- Возможность создания учетной записи на облачной платформе Google
- Делегирование полномочий по всему домену Google Workspace
Создание политик
Создайте политику чтения и управления
vault policy write reader - <<EOF
path "/secret/*" {
capabilities = ["read", "list"]
}
EOF
vault policy write manager - <<EOF
path "/secret/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
EOF
Настройка аутентификации OIDC
Вам понадобится client_id, client_secret, а также адрес электронной почты суперадминистратора, полученный в предыдущих шагах.
vault write auth/oidc/config -<<EOF
{
"oidc_discovery_url": "https://accounts.google.com",
"oidc_client_id": "<YOUR_CLIENT_ID>",
"oidc_client_secret": "<YOUR_CLIENT_SECRET>",
"default_role": "default_role",
"provider_config": {
"provider": "gsuite",
"gsuite_service_account": "/path/to/serviceaccount.json",
"gsuite_admin_impersonate": "<YOUR_SUPER_ADMIN_EMAIL>",
"fetch_groups": true,
"groups_recurse_max_depth": 5
}
}
EOF
Создание default_role
Требует внешний адрес хранилища Vault. Этот шаг можно пропустить если вы тестируете локально/производите локальное тестирование.
vault write auth/oidc/role/default_role \
allowed_redirect_uris="https://VAULT_EXTERNAL_ADDR/ui/vault/auth/oidc/oidc/callback" \
allowed_redirect_uris="http://localhost:8250/oidc/callback" \
user_claim="sub" \
policies="reader" \
groups_claim="groups"
Cоздайте группу Vault и псевдоним группы
vault write identity/group name="manager.group@yourdomain.com" type="external" \
policies="manager" \
metadata=responsibility="Manager Group"
export GROUP_ID="<from_last_output>"
vault auth list -format=json \
| jq -r '."oidc/".accessor' > accessor.txt
vault write identity/group-alias name="manager.group@yourdomain.com" \
mount_accessor=$(cat accessor.txt) \
canonical_id="$GROUP_ID"
Проверьте настройки запуска
Давайте представим, что есть пользователь john.doe@yourdomain.com и он является частью/участником группы GSuite manager.group@yourdomain.com. После настройки по вышеуказанным шагам, вход в хранилище через интерфейс командной строки должен выглядеть следующим образом:
$ vault login -method=oidc
...
Key Value
--- -----
token <TOKEN>
token_accessor <TOKEN_ACCESSOR>
token_duration 768h
token_renewable true
token_policies ["default" "reader"]
identity_policies ["manager"]
policies ["default" "manager" "reader"]
token_meta_role default_role
Логин/вход в систему будет работать как следует, т.к политика управления будет отображаться в identity_policies, которая маппируется через группу manager.group@yourdomain.com.
Я решил написать данную статью именно по той причине, что документация Vault не объясняет все процессы полностью.
Данная статья написана с целью упростить восприятие, т.к базовая документация Vault недостаточно подробно посвящает в этот процесс. Мне потребовалось немало времени, чтобы собрать воедино всю информацию из кейсов GitHub и запросов на включение кода. Надеюсь, что эти рекомендации помогут сэкономить время и наладить процесс авторизации пользователей в хранилище с помощью групп G Suite.