Используемые термины: 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.remontka.com/-/jwks» bound_issuer=»gitlab.remontka.com»
* данная настройка скажет нашей системе Vault, что можно принимать запросы jwt от узла gitlab.remontka.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.
