Доступ к паролям в Hashicorp Vault для GitLab
Обновлено:
Опубликовано:
Используемые термины: Hashicorp Vault, GitLab.
Наша задача состоит в том, чтобы связать Vault и GitLab — последний должен забирать секреты, хранящиеся в централизованном хранилище. Предполагается, что у нас уже есть серверы Vault и GitLab. В противном случае, обращаем внимание на инструкции:
- Установка, настройка и работа с Hashicorp Vault.
- Установка GitLab на Ubuntu.
- Установка GitLab на CentOS.
Для примера, мы вытащим логин и пароль для доступа к базе данных MariaDB. Мы будем использовать механизм JSON Web Token (JWT), который поддерживается в GitLab, начиная с версии 12.10.
Настройка Vault
Разрешим механизм работы с секретами по пути secret:
vault secrets enable -path=secret/ kv
Создадим секрет по пути secret/projects/test/mariadb и добавим 2 записи:
vault kv put secret/projects/test/mariadb login=testuser password=testpassword
* в созданном секрете будет храниться две пары login=testuser и password=testpassword. Именно эти данные мы и должны будем получить в GitLab.
Разрешаем механизм JWT:
vault auth enable jwt
Создаем политику доступа к секрету:
vault policy write project-test - <<EOF
path "secret/projects/test/*" {
capabilities = [ "read" ]
}
EOF
* политика с названием project-test описывает доступ только на чтение к секрету secret/projects/test.
Создаем роль:
vault write auth/jwt/role/project-test - <<EOF
{
"role_type": "jwt",
"policies": ["project-test"],
"token_explicit_max_ttl": 60,
"user_claim": "user_email",
"bound_claims": {
"project_id": "2",
"ref": "master",
"ref_type": "branch"
}
}
EOF
* где обратим внимание на:
- role_type — роль типа jwt (JSON Web Token) для создания токенов доступа, основанный на формате JSON.
- policies — привязываем роль к ранее созданной политике.
- project_id — идентификатор проекта в GitLab, к которому будет привязана данная роль. Другие проекты не смогут взаимодействовать с ней и получать доступ к секретам.
Настраиваем конфигурацию для проверки запросов от гитлаба:
vault write auth/jwt/config jwks_url="http://gitlab.dmosk.com/-/jwks" bound_issuer="gitlab.dmosk.com"
* данная настройка скажет нашей системе Vault, что можно принимать запросы jwt от узла gitlab.dmosk.com.
Настройка GitLab
На стороне GitLab нам необходимо настроить runner и создать файл .gitlab-ci.yml. Подробно процесс описан в инструкции Настройка CI/CD в GitLab для синхронизации проекта с веб-серверами.
Теперь необходимома на компьютере с установленным раннером установить клиента vault. По сути, последний не подразделяется на сервер и клиента — подробнее читаем в инструкции Установка, настройка и работа с Hashicorp Vault. В случае использования Docker-контейнера как среды запуска pipeline, необходимо использовать образ с клиентом vault внутри — об этом также написано в вышеозвученной статье.
Акцентируем внимание на тестовом сценарии. И так, в корне проекта создаем файл .gitlab-ci.yml со следующим содержимым:
stages:
- test_vault
test:
stage: test_vault
script:
- echo $CI_COMMIT_REF_NAME
- export VAULT_SKIP_VERIFY=true
- export VAULT_ADDR=https://10.0.2.5:8200
- export VAULT_TOKEN="$(vault write -field=token auth/jwt/login role=project-test jwt=$CI_JOB_JWT)"
- export LOGIN="$(vault kv get -field=login secret/projects/test/mariadb)"
- export PASSWORD="$(vault kv get -field=password secret/projects/test/mariadb)"
- echo $LOGIN
- echo $PASSWORD
В нашем проекте переходим в раздел CI/CD - Pipelines и запускаем наш сценарий. После окончания его работы кликаем по значку зеленой галочки и в открывшейся странице кликаем по нашей единственной стадии:
Мы должны увидеть наши логин и пароль, которые GitLab запросил у Vault.
