Історія успіху DIY від команди, яка впровадила HashiCorp Vault для керування секретами Kubernetes
Вступ
Це вигадана історія про команду, яка була розгромлена після аудиту безпеки через зберігання облікових даних бази даних у відкритому вигляді для свого веб-додатку.
Дізнайтеся, як вони пройшли шлях з нуля до використання динамічного, масштабованого та безпечного робочого процесу за допомогою HashiCorp Vault за 5 кроків.
У цьому блозі ми охопимо наступні теми:
- Налаштування автентифікації Vault AppRole
- Налаштування та використання External Secrets Manager
- Налаштування автентифікації Vault для Kubernetes
- Налаштування та використання Vault Secrets Operator
- Налаштування та використання Vault Agent Injector
- Налаштування механізму секретів Vault для бази даних Postgres
Додаток
Перш за все, давайте поговоримо про додаток, який буде використовуватися в цьому блозі. Сам додаток досить простий, з ~100 рядків коду. Це веб-додаток, який бере кілька змінних середовища (DB_HOST, DB_PORT, DB_USER, DB_PASSWORD і DB_NAME) і підключається до бази даних Postgres. Потім він відображає облікові дані та статус підключення на веб-сервері, що працює на порту 9090.
Додаток контейнеризований (falcosuessgott/vault-from-zero-to-hero), що означає, що його буде розгорнуто як Deployment в кластері Kubernetes. Після того як demo-app буде розгорнуто та працюватиме з наданими обліковими даними Postgres, веб-сервер відповість коротким повідомленням про статус і поверне 200 (OK) або 500 (помилка):
> curl localhost:9090
DB: 127.0.0.1:5432
User: postgres
Password: P@ssw0rd
Ping: success
Цей demo-app буде використовуватися протягом цього блогу для демонстрації того, як облікові дані бази даних були отримані та надані додатку.
Як працює цей блог
Ви можете виконати всі кроки, зазначені тут, самостійно. Я опишу, як налаштувати всі компоненти та виконати налаштування локально за допомогою docker та kind.
Скорочено
Якщо ви занадто лінивий, щоб слідувати інструкціям, просто перегляньте E2E пайплайни GitHub Action, які виконують всі кроки, зазначені в цьому блозі (перейдіть до кроку deploy).
Попередні вимоги
Щоб слідувати інструкціям, вам потрібно мати встановлені наступні інструменти:
dockerkubectlkindvaulthelmcurljq
Репозиторій
Усі необхідні скрипти та конфігурації доступні в цьому репозиторії. Ви можете просто клонувати його:
> git clone https://github.com/clear-route/hashicorp-vault-from-zero-to-hero.git
> cd hashicorp-vault-from-zero-to-hero
Makefile містить всі необхідні команди для запуску кожної частини для вашої зручності.
Kubernetes
Нам потрібен локальний кластер Kubernetes. Для цього блогу я буду використовувати kind, але ви можете використовувати будь-який дистрибутив Kubernetes, який вам зручний та доступний. Якщо ви використовуєте kind, ви можете використати наступний скрипт для створення кластера kind:
# scripts/setup-kind.sh
# Запускаємо кластер Kubernetes за допомого
--config manifests/kind-config.yml
Після налаштування команда kubectl get ns повинна пройти успішно:
> kubectl get ns
NAME STATUS AGE
default Active 30s
kube-node-lease Active 30s
kube-public Active 30s
kube-system Active 30s
local-path-storage Active 25s
Postgres
Нам також потрібна база даних Postgres. Ось команда, яка запускає локальну базу даних postgres:
# scripts/setup-postgres.sh
# Запускаємо контейнер з postgres
docker run -d --rm \
--name postgres \
-p 5432:5432 \
-e POSTGRES_USER=postgres \
-e POSTGRES_PASSWORD=P@ssw0rd \
-e POSTGRES_DB=vault \
postgres
Vault
Нарешті, нам потрібен екземпляр Vault.
Я буду використовувати контейнер Vault на базі docker, з попередньо заданим токеном Vault для простоти:
# scripts/setup-vault.sh
# Запускаємо контейнер Vault
docker run -d --rm \
--add-host host.docker.internal:host-gateway \
--cap-add=IPC_LOCK \
--name vault \
-p 8200:
-e VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200 \
hashicorp/vault
Після того як ви налаштуєте змінні середовища для Vault:
export VAULT_ADDR="http://127.0.0.1:8200"
export VAULT_TOKEN="root"
команда vault status повинна повернути здоровий екземпляр Vault:
> vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 1
Threshold 1
Version 1.18.3
Build Date 2024-12-16T14:00:53Z
Storage Type inmem
Cluster Name vault-cluster-0107973c
Cluster ID e39a93ab-6eda-1223-4894-0f7a6c867776
HA Enabled false
Очищення
Якщо ви досягли тупика, ви завжди можете скинути своє локальне середовище:
# scripts/cleanup.sh
# Видалити кластер kind
kind delete cluster --name vault-from-zero-to-hero
# Зупинити та видалити docker-образи
docker stop vault postgres
docker rm vault postgres
Поточний стан: Жорстко задані статичні облікові дані у відкритому вигляді
Гаразд, ми готові до роботи. Поточний стан для нашої вигаданої команди та їхнього управління секретами не міг бути гіршим, і я серйозно — Ніколи не робіть цього — навіть не в розробці.
Команда просто передавала облікові дані бази даних у свій додаток, вказуючи необхідні змінні середовища в маніфесті Deployment:
# manifests/demo-app-hardcoded.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
labels:
app: demo-app
spec:
replicas: 1
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: vault-from-zero-to-hero
image: falcosuessgott/vault-from-zero-to-hero
ports:
- containerPort: 9090
env:
- name: DB_HOST
value: "172.17.0.1"
- name: DB_PORT
value: "5432"
- name: DB_USER
value: postgres
# Це погано - не робіть так!
- name: DB_PASSWORD
value: P@ssw0rd
- name: DB_NAME
value: vault
Незважаючи на всі питання безпеки, — додаток demo-app працює як очікується. Після розгортання ми можемо побачити, що з’єднання з базою даних було успішно встановлено, використовуючи надані облікові дані:
> kubectl apply -f manifests/demo-app-hardcoded.yaml
> kubectl exec $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}') -- curl --fail-with-body -s localhost:9090
DB: 172.17.0.1:5432
User: postgres
Password: P@ssw0rd
Ping: success
Як і можна було очікувати, під час аудиту команда безпеки знайшла жорстко задані облікові дані в їхньому репозиторії Git і помітила цей додаток. Ось де починається наша історія про впровадження HashiCorp Vault.
Частина 02: Статичні облікові дані від HashiCorp та External Secrets Manager — [⭐]
Після аудиту команді більше не дозволялося жорстко задавати облікові дані бази даних у відкритих маніфестах Kubernetes. Їм потрібно було знайти рішення для керування секретами. На щастя, інфраструктурна команда вже підтримувала кластер HashiCorp Vault для внутрішнього використання.
Команда провела дослідження щодо Vault і дізналася, що вони можуть зберігати облікові дані бази даних у механізмі секретів KVv2 Vault.
Після отримання доступу до Vault один з учасників команди вніс облікові дані в уже існуючий механізм Kvv2 секретів:
# записуємо секрети у Vault
> vault kv put secret/database/postgres username=postgres password=P@ssw0rd
======== Шлях до секрету ========
secret/data/database/postgres
======= Метадані =======
Ключ Значення
--- -----
created_time 2025-01-05T22:49:52.814816755Z
custom_metadata
deletion_time n/a
destroyed false
version 1
# список секретів
> vkv export -p secret --show-values
secret/ [desc=key/value секретне сховище] [type=kv2]
└── database
└── postgres [v=1]
├── password=P@ssw0rd
└── username=postgres
Тепер все, що їм залишалося зробити — це помістити секрет Vault KVv2 у Kubernetes секрет, так? Після додаткових досліджень команда додатку дізналася про External Secrets Manager (ESM) — оператора Kubernetes, який синхронізує Kubernetes Secrets з різних постачальників, таких як HashiCorp Vault.
Налаштування External Secrets Manager
Встановлення було досить простим.
Вони просто мали використати helm chart для встановлення оператора:
# scripts/setup-esm.sh
# додаємо репозиторій ESM helm chart
helm repo add external-secrets https://charts.external-secrets.io
# отримуємо чарт
helm repo update
# встановлюємо ESM helm chart
helm install external-secrets \
external-secrets/external-secrets \
-n external-secrets \
--create-namespace \
--set installCRDs=true
# чекаємо, поки ESM контейнери стануть готовими
kubectl wait \
--for=condition
--timeout=180s \
-n external-secrets
Потім, згідно з документацією, був потрібен CRD типу SecretStore, що вказує на з'єднання з Vault і шлях до механізму секретів KVv2:
# manifests/esm-secret-store-token.yml
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: vault-backend
spec:
provider:
vault:
server: http://172.17.0.1:8200
path: secret
version: v2
auth:
tokenSecretRef:
name: vault-token
key: token
---
apiVersion: v1
kind: Secret
metadata:
name: vault-token
data:
token: cm9vdA== # "root"
Нарешті, був потрібен ExternalSecret CRD, який посилається на SecretStore і вказує, що секрет Kvv2 має бути синхронізований з Kubernetes секретом:
# manifests/esm-external-secret.yml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: postgres-creds
spec:
refreshInterval: "1h"
secretStoreRef:
name: vault-backend
kind: SecretStore
target:
name: postgres-creds
data:
- secretKey: username
remoteRef:
key: database/postgres
property: username
- secretKey: password
remoteRef:
key: database/postgres
property: password
Після застосування маніфестів, вони побачили, що дійсно Kubernetes Secret під назвою postgres-creds був заповнений обліковими даними бази даних з Vault:
> kubectl get secret postgres-creds -o json | jq '.data | map_values(@base64d)'
{
"password": "P@ssw0rd",
"username": "postgres"
}
Виглядає чудово! Тепер усе, що залишалося зробити — це посилатися на секрет postgres-creds в маніфесті розгортання додатку за допомогою envFrom:
# manifests/demo-app-k8s-secret.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
labels:
app: demo-app
spec:
replicas: 1
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: vault-from-zero-to-hero
image: falcosuessgott/vault-from-zero-to-hero
ports:
- containerPort: 9090
env:
- name: DB_HOST
value: "172.17.0.1"
- name: DB_PORT
value: "5432"
- name: DB_USER
valueFrom:
secretKeyRef:
name: postgres-creds
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: postgres-creds
key: password
- name: DB_NAME
value: vault
І ... Voilà, demo-app запущено і він успішно підключається до бази даних postgres за допомогою облікових даних, збережених у Vault:
> kubectl apply -f manifests/demo-app-k8s-secret.yaml
> kubectl exec $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}') -- curl --fail-with-body -s localhost:9090
DB: 172.17.0.1:5432
User: postgres
Password: P@ssw0rd
Ping: success
Команда була задоволена, вони прийняли Vault як рішення для управління секретами і більше не потрібно було хардкодити облікові дані бази даних в маніфесті demo-app. Усі питання, виявлені під час аудиту, були вирішені, і тепер команда могла зосередитись на розробці нових функцій...
правда?
Частина 03: Статичні облікові дані з HashiCorp Vault за допомогою Approle аутентифікації та External Secrets Manager — [⭐⭐]
Ну, не зовсім, після подальшої консультації з командою безпеки, було виявлено, що тепер вони більше не хардкодять облікові дані postgres, але тепер у них є base64 закодований Vault токен у SecretStore CRD, і, що ще гірше, цей токен має доступ до набагато більшої кількості секретів, ніж це необхідно... Команда додатка ще не закінчила. Вони разом з командою інфраструктури розробили більш безпечний робочий процес аутентифікації для Vault і вирішили використати метод аутентифікації Approle.
Налаштування аутентифікації Vault за допомогою Approle
Approle — це метод аутентифікації, який дозволяє машинам або додаткам аутентифікуватися в Vault за допомогою role-id та secret-id. Команда Vault надала їм облікові дані Approle, пов'язані з політикою postgres, яка після аутентифікації дозволяє лише читати з шляху database/postgres, де зберігаються облікові дані postgres:
# scripts/setup-vault-approle-auth.sh
# увімкнути аутентифікацію Approle
vault auth enable approle
# створити політику для облікових даних бази даних
vault policy write approle - < kubectl apply -f manifests/demo-app-k8s-secret.yaml
> kubectl exec $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}') -- curl --fail-with-body -s localhost:9090
DB: 172.17.0.1:5432
User: postgres
Password: P@ssw0rd
Ping: success
Команда знову звернулась за відгуками до команди безпеки, думаючи, що вони вирішили всі залишкові проблеми з хардкоденим токеном. Хоча команда безпеки була задоволена тим, що тепер вони використовують метод аутентифікації, який надає токен Vault з доступом лише для читання до шляху database/postgres, вони все ще мали занепокоєння з приводу хардкодених облікових даних Approle у vault-approle Kubernetes секреті.
Частина 04: Статичні облікові дані з HashiCorp Vault за допомогою Kubernetes аутентифікації та External Secrets Manager — [⭐⭐⭐]
Команді додатка потрібно було знайти інше рішення... Команда інфраструктури повідомила їм про метод аутентифікації Kubernetes для Vault, який, по суті, використовує Kubernetes токен служби для аутентифікації в Vault. Таким чином, їм більше не потрібно буде хардкодити жодних облікових даних:
Налаштування аутентифікації Vault за допомогою Kubernetes
Команда додатка створила vault-auth Kubernetes Service Account з дозволами переглядати інші облікові записи служби за допомогою ролі system:auth-delegator.
Цей обліковий запис служби використовуватиметься Vault для перевірки та валідації токенів інших облікових записів служби:
# manifests/vault-crb.yml
apiVersion: v1
kind: ServiceAccount
metadata:
name: vault-auth
automountServiceAccountToken: true
---
apiVersion: v1
kind: Secret
metadata:
name: vault-auth-token
annotations:
kubernetes.io/service-account.name: vault-auth
type: kubernetes.io/service-account-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: role-tokenreview-binding
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- kind: ServiceAccount
name: vault-auth
namespace: default
Метод аутентифікації Kubernetes було швидко налаштовано для Kubernetes кластера команди додатка. Вони також налаштували роль аутентифікації Kubernetes esm, яка прив'язана до політики postgres:
# scripts/setup-vault-k8s-auth.sh
# увімкнути метод аутентифікації kubernetes
vault auth enable kubernetes
# створити політику
vault policy write postgres - < kubectl apply -f manifests/demo-app-k8s-secret.yaml
> kubectl exec $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}') -- curl --fail-with-body -s localhost:9090
DB: 172.17.0.1:5432
User: postgres
Password: P@ssw0rd
Ping: success
Це було чудово! Вони не лише отримали облікові дані postgres з Vault, а й змогли аутентифікуватися абсолютно динамічно в Vault, використовуючи облікові записи служби Kubernetes.
Тепер їм більше не потрібно було хардкодити жодних статичних облікових даних у жодних маніфестах!
Частина 05: Динамічні облікові дані для бази даних за допомогою Vault Secrets Operator — [⭐⭐⭐⭐]
Команда додатка була захоплена. Вони побачили переваги впровадження HashiCorp Vault і як це не тільки покращило безпеку, але й час, який витрачається на безпечне розгортання додатків, більше не турбуючись про секрети. Вони захотіли ще більше покращити робочий процес і дізналися про движок секретів Database.
і вирішили, що якщо вони вже аутентифіковані в Vault, чому б не використовувати динамічні облікові дані для бази даних postgres?
Налаштування движка секретів Vault для бази даних
Движок секретів database може автоматично генерувати та відкликати облікові дані для різних баз даних, таких як postgres:
Інфраструктурна команда увімкнула движок секретів та налаштувала базу даних команди додатка в Vault (demo-app-db) і надала їм роль для postgres:
# scripts/setup-vault-db.sh
# увімкнути движок секретів для бази даних
vault secrets enable database
# створити базу даних
vault write database/config/demo-app-db \
plugin_name="postgresql-database-plugin" \
allowed_roles="postgres" \
connection_url="postgresql://{{username}}:{{password}}@host.docker.internal:5432/vault" \
username="postgres" \
password="P@ssw0rd"
# створити роль
vault write database/roles/postgres \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
Вони перевірили підключення та змогли генерувати короткострокові облікові дані для postgres за допомогою Vault:
> vault read database/creds/postgres
Key Value
--- -----
lease_id database/creds/postgres/74nOvKCmV6BNUjy5iWE22u4Z
lease_duration 1h
lease_renewable true
password 89ZYmtT2qgS-OG7Avi2T
username v-token-postgres-Zv02fNPCyfXg5gzM3Jzb-1736064877
Налаштування Vault Secrets Operator
Але була одна проблема… External Secrets Manager не працює з динамічними секретами, а лише з KV секретами... На щастя, команда дізналася про Vault Secrets Operator (VSO) — рідний оператор Vault, наданий HashiCorp:
Вони встановили VSO за допомогою Helm:
# scripts/setup-vso.sh
# встановити Helm чарт для VSO
helm repo add hashicorp https://helm.releases.hashicorp.com
# отримати чарт
helm repo update
# встановити чарт для VSO
helm install \
--version 0.9.1 \
--create-namespace \
--namespace vso \
vso hashicorp/vault-secrets-operator
# почекати, поки поди VSO стануть готовими
kubectl wait \
--
-l app.kubernetes.io/instance=vso \
--timeout=180s \
-n vso
# створити політику
vault policy write vso - <
metadata:
name: demo-app
labels:
app: demo-app
spec:
replicas: 1
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: vault-from-zero-to-hero
image: falcosuessgott/vault-from-zero-to-hero
ports:
- containerPort: 9090
env:
- name: DB_HOST
value: "172.17.0.1"
- name: DB_PORT
value: "5432"
- name: DB_NAME
value: vault
- name: DB_USER
valueFrom:
secretKeyRef:
name: dynamic-db-postgres-creds
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: dynamic-db-postgres-creds
key: password
Після застосування, вони перевірили demo-app і побачили, що дійсно тепер облікові дані postgres були динамічно створені за допомогою Vault!:
> kubectl apply -f manifests/demo-app-vso.yaml
> kubectl exec $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}') -c vault-from-zero-to-hero -- curl --fail-with-body -s localhost:9090
DB: 172.17.0.1:5432
User: v-kubernet-postgres-ZGy2wmYeBoVJh1YVwHv2-1736122493 # користувач, створений Vault
Password: nmeS60Lr-ygUo7mJvjOE # пароль, створений Vault
Ping: success
Дуже круто! Тепер для аутентифікації в Vault не потрібні жодні зашиті облікові дані, і для demo-app було надано короткострокові динамічні облікові дані для postgres.
Частина 06: Введення динамічних облікових даних бази даних під час виконання за допомогою Vault Agent Injector — [⭐⭐⭐⭐⭐]
Але на цьому етапі команда додатків запитала себе, чи нам взагалі потрібні Kubernetes секрети на цьому етапі? Якщо Vault генерує секрети, чому б не передавати їх безпосередньо в розгортання demo-app? Замість того, щоб посилатися на Kubernetes секрет?
Це можна зробити за допомогою Vault Agent Injector (VAI).
Розумний робочий процес, який, коли в Pod є визначені певні анотації, впроваджує Sidecar контейнер за допомогою Mutating Webhooks (мутуючих веб-хуків).
Цей контейнер (це контейнер Vault в режимі агента) потім автентифікується в Vault і записує секрети на диск, де контейнер додатку може їх використовувати:
Налаштування Vault Agent Injector
Vault Agent Injector було швидко встановлено за допомогою helm:
# scripts/setup-vai.sh
# інсталюємо Helm чарт VSO
helm repo add hashicorp https://helm.releases.hashicorp.com
# завантажуємо чарти
helm repo update
# інсталю
--create-namespace \
--namespace vai \
--set="global.tlsDisable=true" \
--set="global.externalVaultAddr=http://172.17.0.1:8200" \
--set="injector.enabled=true" \
--set="server.enabled=false"
# чекаємо, поки поди VAI не будуть готові
kubectl wait \
--for=condition=ready pod \
-l app.kubernetes.io/instance=vai \
--timeout=180s \
-n vai
# створюємо політику
vault policy write vai - < kubectl apply -f manifests/demo-app-vai.yaml
> kubectl exec $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}') -c vault-from-zero-to-hero -- curl --fail-with-body -s localhost:9090
DB: 172.17.0.1:5432
User: v-kubernet-postgres-ZGy2wmYeBoVJh1YVwHv2-1736122493
Password: nmeS60Lr-ygUo7mJvjOE
Ping: success
Тепер вони могли масштабувати деплоймент до 5 реплік, щоб показати, що тепер кожен pod запитує свої власні облікові дані бази даних з Vault:
> kubectl scale deployment demo-app --replicas=5
> for pod in $(kubectl get po -l app=demo-app -o jsonpath='{.items[*].metadata.name}');\
do echo $pod && kubectl exec $pod -c vault-from-zero-to-hero -- curl --fail-with-body -s localhost:9090;\
done
demo-app-57d64bdd8f-57h5v
DB: 172.17.0.1:5432
User: v-kubernet-postgres-ZGy2wmYeBoVJh1YVwHv2-1736122493
Password: nmeS60Lr-ygUo7mJvjOE
Ping: success
demo-app-57d64bdd8f-j9w7g
DB: 172.17.0.1:5432
User: v-kubernet-postgres-MdFkJHz8XIYNHOKLkcPZ-1736122358
Password: 2AiPB8sOa-ZQD526bkbV
Ping: success
demo-app-57d64bdd8f-l46q6
DB: 172.17.0.1:5432
User: v-kubernet-postgres-0DBZTF7gMVusunpRRMBH-1736122545
Password: KMtoFRoqxfsP-oKtK3yt
Ping: success
demo-app-57d64bdd8f-t225n
DB: 172.17.0.1:5432
User: v-kubernet-postgres-JdvETwIW8NOpUaV2RJay-1736122493
Password: BCsYBuNYieO-bL2xIdxp
Ping: success
demo-app-57d64bdd8f-v87fl
DB: 172.17.0.1:5432
User: v-kubernet-postgres-E7PVaLuXZBBqGPW5I1QR-1736122545
Password: UHHPbsCF6jLzd-bC3V55
Ping: success
Куди йти далі
Навіщо зупинятись на цьому етапі? Хороша новина для Vault полягає в тому, що як тільки механізм автентифікації налаштовано, можливості безмежні.
Тепер команда могла б також впровадити PKI (Public Key Infrastructure) секрети від Vault, щоб автоматично генерувати TLS сертифікати для своїх додатків, або ж використати Vault Transit engine для шифрування даних перед записом їх до бази даних.
Підсумок
І на цьому все! Це кінець нашої маленької вигаданої історії команди, яка почала без жодного рішення для управління секретами та змогла мігрувати до потужного, динамічного та безпечного робочого процесу за допомогою HashiCorp Vault.
Сподіваюся, вам сподобалась ця подорож і ви дізнались щось нове. До зустрічі незабаром 🙂
Перекладено з: HashiCorp Vault — From Zero to Hero