ADMINS24

Как настроить аутентификация и чтение секретов в GitLab через Hashicorp Vault

Администрирование
Обновлено Обновлено: Опубликовано Опубликовано:

Используемые термины: Hashicorp Vault, GitLab.

Наша задача состоит в том, чтобы связать Vault и GitLab — последний должен забирать секреты, хранящиеся в централизованном хранилище. Предполагается, что у нас уже есть серверы Vault и GitLab. В противном случае, обращаем внимание на инструкции:

Для примера, мы вытащим логин и пароль для доступа к базе данных MariaDB. Мы будем использовать механизм JSON Web Token (JWT), который поддерживается в GitLab, начиная с версии 12.10.

Настройка Hashicorp Vault
Настройка CI/CD в GitLab

Настройка 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.admins24.com/-/jwks» bound_issuer=»gitlab.admins24.com»

* данная настройка скажет нашей системе Vault, что можно принимать запросы jwt от узла gitlab.admins24.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 и запускаем наш сценарий. После окончания его работы кликаем по значку зеленой галочки и в открывшейся странице кликаем по нашей единственной стадии:

Кликаем по названию нашей стадии pipeline

Мы должны увидеть наши логин и пароль, которые GitLab запросил у Vault.