Захист секретів у CI/CD: інтеграція HashiCorp Vault Secret у GitLab-пайплайни

TelegramУсі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт! Мене звати Роман, я служу в ЗСУ, де обіймаю посаду т.в.о. начальника інформаційно-телекомунікаційного вузла. Ціную свою роботу та відчуваю велику відповідальність за забезпечення стабільного зв’язку. Однак моя професійна дорога раніше не була такою: я захоплювався програмуванням, та життя змусило мене змінити напрям. На початку служби пройшов навчання за курсом CCNA і отримав хороший досвід в проєктуванні мереж, оптоволоконного та кабельного зв’язку. Мене завжди цікавили сервери та мережеве обладнання. І хоча мені подобався DevOps, бойові дії обмежили час для глибокого занурення в цю сферу. Але я не здавався і використовував вільну хвилину для самоосвіти, особливо після знайомства з інструментами DevOps та хмарними середовищами. Мій інтерес призвів до вивчення Vault Secret, який став інструментом для зберігання секретів в процесі CI/CD. Саме ця тема стала приводом написання статті. У майбутньому я планую написати про застосування Vault Secret з такими інструментами як Terraform та Kubernetes, продемонструвати реальні приклади та роботу Vault Secret занесення секретів через CLI.

Інтеграція HashiCorp Vault Secret: огляд, переваги та недоліки

HashiCorp Vault є однією з найбільш популярних систем керування секретами, яка дозволяє зберігати, управляти та контролювати доступ до конфіденційної інформації, такої як паролі, ключі API, токени тощо. Розгляньмо інтеграцію Vault Secret, його можливості та відомі плюси та мінуси.

Інтеграція

Згідно з документацією, Vault Secrets може інтегруватися з численними сервісами та платформами. Деякі із цих інтеграцій містять:

  • Платформи розробки: GitLab CI/CD, Jenkins, CircleCI тощо.
  • Обчислювальні платформи: AWS, Azure, DigitalOcean, GCP, Kubernetes тощо.
  • Системи управління базами даних: PostgreSQL, MySQL, MongoDB тощо.
  • Інші сервіси: RabbitMQ, Consul, Kafka тощо.


Навіщо це потрібно

Безпека: ваші секрети захищені від несанкціонованого доступу. Централізоване сховище: усі секрети перебувають в одному місці, що спрощує їх керування. Динамічні секрети: Vault може генерувати секрети на льоту, які автоматично виринають після певного часу. Аудит: забезпечує засоби для відстежування того, хто, коли та які секрети використовував.

Плюси

Висока безпека: за допомогою шифрування, автентифікації та контролю доступу, Vault забезпечує якісний рівень безпеки для ваших секретів. Широкі можливості інтеграції: інтеграція з численними платформами та сервісами. Масштабованість: Vault може легко масштабуватися для великих організацій та систем. Динамічне створення секретів: створення тимчасових облікових записів для баз даних чи хмарних сервісів.

Мінуси

Складність: для новачків може бути важко освоїти Vault, особливо для великих інфраструктур. Вимоги до керування: необхідність регулярно оновлювати, налаштовувати та моніторити. Залежність: якщо Vault вийде з ладу, доступ до секретів може бути заблокований.

Приклад встановлення та автентифікації в GitLab CI/CD

Його можна інтегрувати з GitLab CI/CD, щоб безпечно зберігати і використовувати секрети прямо в пайплайнах GitLab. Розгляньмо докладно цей процес.

Встановлення Vault в пайплайн

Для початку, нам потрібно встановити інструмент командного рядка Vault, який називається vlt. Це можна зробити в розділі before_script вашого .gitlab-ci.yml:

before_script:
- wget https://releases.hashicorp.com/vlt/0.2.2/vlt_0.2.2_linux_amd64.zip
- unzip ./vlt_0.2.2_linux_amd64.zip -d /usr/local/bin/
- chmod +x /usr/local/bin/vlt

Встановлення з’єднання з Vault Secret

Далі потрібно встановити з’єднання між вашим пайплайном і Vault. Для цього треба автентифікуватися:

script:
- export HCP_CLIENT_ID=$HCP_CLIENT_LOG
- export HCP_CLIENT_SECRET=$HCP_CLIENT_PASS
- vlt login

Тут HCP_CLIENT_ID і HCP_CLIENT_SECRET — це змінні середовища, які мають бути передані до вашого CI/CD-середовища. Ці змінні слід зберігати в секретних змінних GitLab.

Використання секретів

Тепер, коли ми з’єдналися з Vault, можемо отримувати необхідні секрети:

script:
- export DOCKER_USER=$(vlt secrets get --app-name="your-app-name" --plaintext DOCKER_USER)
- export DOCKER_PASS=$(vlt secrets get --app-name="your-app-name" --plaintext DOCKER_PASS)

Використовуючи команду vlt secrets get, ви можете отримувати секрети, збережені в Vault, і послуговуватися ними у вашому пайплайні.

Приклад використання в моєму пайплайні:


  before_script:

    - apk update

    - apk add --no-cache gpg wget lsb-release curl apt unzip 

# Тут я встановлюю необхідні пакети для мого пайплайну! 

# І головне — unzip. Якщо його немає в образі docker image, в якому ви це виконуєте

    # .... /// K8S автентифікація і тд...

   - wget https://releases.hashicorp.com/vlt/0.2.2/vlt_0.2.2_linux_amd64.zip 

   - unzip ./vlt_0.2.2_linux_amd64.zip -d /usr/local/bin/ 

   - chmod +x /usr/local/bin/vlt

   - echo "Vault installed" # Встановлення завершенно

   - export HCP_CLIENT_ID=$HCP_CLIENT_LOG

   - export HCP_CLIENT_SECRET=$HCP_CLIENT_PASS
# /// Для автентифікації ми попередньо занесли ці дві змінні до GitLab Vault. І тепер використовуємо їх.

  

  script:

    - vlt login  # Виконання автентифікації.

    - echo "$CI_REGISTRY_PASSWORD" | docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY # Тут як приклад використання автентифікації без Vault Secret для доступу до GitLab.regestry (образи docker image)

     - export IAM_K8S_CLUSTER=$(vlt secrets get —app-name="ім’я_додатку" --plaintext IAM_K8S_CLUSTER) 
# І власне перенесення секретів з Vault в змінні gitlab 
# Змінній IAM_K8S_CLUSTER буде присвоєне значення з Vault Secret додаток, який ви зазначите з ім’я секрету ( IAM_K8S_CLUSTER)

 І далі так само
    - export IAM_SERVICE=$(vlt secrets get --app-name="ім’я_додатку" --plaintext IAM_SERVICE_K8S)
    - export DOCKER_USER=$(vlt secrets get --app-name="ім’я_додатку" --plaintext GITLAB_DOCKER_REGISTRY_USER)
    - export DOCKER_PASS=$(vlt secrets get --app-name="ім’я_додатку" --plaintext GITLAB_DOCKER_REGISTRY_PASS)
    - export DOCKER_REGISTRY=$(vlt secrets get --app-name="ім’я_додатку" --plaintext GITLAB_DOCKER_REGISTRY)
    - export KUBE_CONFIG=$(vlt secrets get --app-name="ім’я_додатку" --plaintext DO_KUBERNETIS_TOKEN)
# /// Далі в мене команди пішли до налаштування K8S та розгортання додатку

Результат

10050K .......... .......... .......... .......... .......... 99% 363M 0s
636$ 10100K .......... .......... .......... ......... 100% 280M=0.2s
637$ 2023-09-15 13:42:15 (61.7 MB/s) - 'vlt_0.2.2_linux_amd64.zip' saved [10382668/10382668]
638$ unzip ./vlt_0.2.2_linux_amd64.zip -d /usr/local/bin/
639$ Archive: ./vlt_0.2.2_linux_amd64.zip
640$ inflating: /usr/local/bin/vlt
641$ chmod +x /usr/local/bin/vlt
642$ vlt login
643$ Successfully logged in
644$ echo "$CI_REGISTRY_PASSWORD" | docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
645$ WARNING! Using --password via the CLI is insecure. Use --password-stdin.
646$ Login Succeeded
647$ export IAM_K8S_CLUSTER=$(vlt secrets get --app-name="your_app" --plaintext IAM_K8S_CLUSTER)
648$ WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
649$ Configure a credential helper to remove this warning. See
650$ https://docs.docker.com/engine/reference/commandline/login/#credentials-store
651$ export IAM_SERVICE=$(vlt secrets get --app-name="your_app" --plaintext IAM_SERVICE_K8S)
652$ export DOCKER_USER=$(vlt secrets get --app-name="your_app" --plaintext GITLAB_DOCKER_REGISTRY_USER)
653$ export DOCKER_PASS=$(vlt secrets get --app-name="your_app" --plaintext GITLAB_DOCKER_REGISTRY_PASS)
654$ export DOCKER_REGISTRY=$(vlt secrets get --app-name="your_app" --plaintext GITLAB_DOCKER_REGISTRY)
655$ export KUBE_CONFIG=$(vlt secrets get --app-name="your_app" --plaintext DO_KUBERNETIS_TOKEN)
656$ cp $CI_PROJECT_DIR/DO/config.yaml ./.config/doctl/config.yaml
657$ doctl auth init -t "$KUBE_CONFIG"
658$ Using token for context default
659$ Validating token... ✔

Висновки

HashiCorp Vault — це потужний інструмент, і його інтеграція з CI/CD може суттєво підвищити безпеку та ефективність процесу розробки, який пропонує високий рівень безпеки та гнучкість. Однак така потужність йде поруч з певною складністю, тому перед використанням Vault великі організації повинні ретельно вивчити його можливості та розглянути ймовірні виклики.

Розглянутий метод, який використовує змінні, слугує лише для ознайомлення. Для використання Vault Secret у GitLab CI/CD рекомендується вдатися до нативного методу передачі секретних даних, який забезпечує високий рівень їх безпеки. Додаткову інформацію можна знайти за посиланням: docs.gitlab.com/ee/ci/secrets

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Зі свого досвіду скажу, що ГітЛаб гарний для CI, але деплоймент повинен відбуватися в інших місцях. Тому зберігати секрети у ГітЛаб саме то. Vault додає більше роботи та вимогає зайвої підтримки.

А якщо хтось потім зробить зміну до пайплану, та додасть `echo $YOUR_SECRET`?

Дякую за статтю і службу. В принципі як і кажуть трохи нижче — бувають і більш ефективні рішення — такі як нативна інтеграція з гітлабом, але якщо рішення працює — то можна з нього і починати і вже далі вдосконалювати step by step. І вітаю з першою статтею на доу)

Навіщо ці танці з бубном та vlt secrets get, якщо у GitLab є нативна інтеграція для цього docs.gitlab.com/ee/ci/secrets

vlt secrets get щоб розкрити тему глибше, з корення, від встановлення до використання!

розгляньте варіант коли на проекті уже є vlt задіяний у інших автоматизованих процесах, і тут стартує CI/CD на GitLab чи на альтернативі де все аналогічно
стаття норм

Можна вигадати нескінченну кількість причин, щоб виправдати будь-що. Коли стаття під назвою

інтеграція HashiCorp Vault Secret у GitLab-пайплайни

навіть не згадує про можливість нативного використання, скоріше за все, просто не було приділено достатньо уваги до підготовки та збору інформації перед її написанням

Чи завжди, коли ви ознайомлюєтесь з новим інструментом, ви намагаєтеся вивчити всі його можливості одразу, чи вибираєте більш прагматичний підхід і спрямовуєте своє навчання на конкретні аспекти, які вам дійсно потрібні? Одразу вивчати усі деталі і функції інструмента не завжди є раціональним підходом, особливо коли ви вперше з ним знайомитесь.

Спроба охопити всі можливості одразу може призвести до заплутання та втрати основної мети вашого навчання. Я писав цю статтю з орієнтацією на початківців (рівень junior) або тих, хто шукає загальний огляд інструменту. Для багатьох з нас найбільш ефективним підходом є спочатку засвоїти основні концепції та можливості інструмента, а потім, при необхідності, докладніше вивчати конкретні аспекти або функції.

У кінцевому підсумку, це питання індивідуальне, і кожна людина може вибирати свій власний підхід до вивчення нових інструментів відповідно до своїх потреб та мети. Головне — це зберігати баланс між загальним розумінням і глибоким вивченням, а також не боятися навчатися та розвиватися відповідно до обраного напрямку.

Дякую за спілкування, та кількість уваги!

Чи завжди, коли ви ознайомлюєтесь з новим інструментом, ви намагаєтеся вивчити всі його можливості одразу, чи вибираєте більш прагматичний підхід і спрямовуєте своє навчання на конкретні аспекти, які вам дійсно потрібні?

Загальноприйнятими правилами є вивчити наявні рішення. Як зазначили вище — наявне рішення є: docs.gitlab.com/ee/ci/secrets
А вашому велосипеду з «export DOCKER_PASS=$(vlt secrets get)» для повноти не вистачає ще «echo $DOCKER_PASS» — ну так, чисто перевірити що с «секретом» все ок

А найгірше тут — що хтось це прочитає, і вирішить, що так і треба — бач, розумний дядько тут написав.

Це не є рекомендований підхід, а лише ознайомчий! І ви абсолютно правильно зауважили, що в Gitlab існує нативний підхід з використанням Vault. При його використанні рівень безпеки відповідає потребам.
Ця стаття є моєю першою, і можливо, варто було обрати інший заголовок, або розглянути докладніше нативний підхід або додати попередження: «Не рекомендовано для використання в командах, яким ви не довіряєте!»

Чи завжди, коли ви ознайомлюєтесь з новим інструментом, ви намагаєтеся вивчити всі його можливості одразу

Так, особливо коли мені потрібно вирішити специфічне питання. Але в даному випадку можна просто загуглити «gitlab ci/cd hashicorp vault»

Спроба охопити всі можливості одразу може призвести до заплутання та втрати основної мети вашого навчання

Бла бла бла

Я писав цю статтю з орієнтацією на початківців

Жаль цих людей. Адже подекуди те та як ми навчилися вперше дуже важко викорінити

Для багатьох з нас найбільш ефективним підходом є спочатку засвоїти основні концепції та можливості інструмента, а потім, при необхідності, докладніше вивчати конкретні аспекти або функції

Бла бла бла

тих, хто шукає загальний огляд інструменту

Стаття приділяє увагу лише одному — використанню GitLab CI/CD разом з Vаult. Це не є загальним огляд

У кінцевому підсумку, це питання індивідуальне, і кожна людина може вибирати свій власний підхід до вивчення нових інструментів відповідно до своїх потреб та мети. Головне — це зберігати баланс між загальним розумінням і глибоким вивченням, а також не боятися навчатися та розвиватися відповідно до обраного напрямку

Тут я уже буквально потонув

Ви, мабуть, працюєте в Гугл або Фейсбук. Ваш високий рівень, як інженера, кидається в очі.

Ні. Я багато чого ще не знаю і багато чого треба вивчити. Просто не подобається коли починають маніпулювати темою та ціллю дискусії

Підписатись на коментарі