Как настроить и использовать проекты Hashicorp Vault и Consul

В следующем руководстве подробно описано, как настроить и использовать проекты Hashicorp Vault и Consul для безопасного хранения секретов и управления ими.

Мы начнем с запуска одного экземпляра Vault в контейнере Docker, а затем перейдем к управлению как статическими, так и динамическими секретами вместе с функцией Vault «шифрование как услуга». Затем мы добавим Consul и посмотрим, как масштабировать Vault.

Основные зависимости:

  • Докер v20.10.8
  • Докер-композитор v1.29.2
  • Убежище v1.8.2
  • Консул v1.10.2

Цели

К концу этого урока вы должны уметь:

  1. Объясните, что такое Vault и почему вы можете захотеть его использовать.
  2. Описать базовую архитектуру Vault, а также динамические и статические секреты, различные серверные части (хранилище, секрет, аутентификация, аудит) и то, как Vault можно использовать в качестве «шифрования как услуги».
  3. Настройте и запустите Vault и Consul с помощью Docker
  4. Раскрутите Vault с помощью серверной части файловой системы
  5. Инициализировать и распечатать хранилище
  6. Аутентификация в хранилище
  7. Настройте серверную часть аудита для регистрации всех взаимодействий с Vault.
  8. Работайте со статическими и динамическими секретами через интерфейс командной строки, HTTP API и пользовательский интерфейс.
  9. Создайте политику Vault, чтобы ограничить доступ к определенному пути
  10. Используйте серверную часть Transit как «шифрование как услугу».
  11. Настройте Consul для работы с Vault в качестве хранилища для секретов.
  12. Определите пользовательский период аренды для секрета и отзовите секрет до окончания этого периода.

Что такое Сейф?

Vault — это инструмент с открытым исходным кодом, используемый для безопасного хранения секретов и управления ими.

Что такое секрет? Секреты в контексте этого руководства — это конфиденциальная или личная информация, такая как учетные данные базы данных, ключи SSH, имена пользователей и пароли, учетные данные AWS IAM, токены API, номера социального страхования, номера кредитных карт и т. д.

Найдите минутку, чтобы подумать о том, как ваша команда в настоящее время управляет секретами и распределяет их:

  1. Кто имеет к ним доступ?
  2. Кто ими управляет?
  3. Как вы контролируете, кто имеет к ним доступ?
  4. Как ваши приложения получают их?
  5. Как они обновляются?
  6. Как они отзываются?

Vault дает ответы на эти вопросы и помогает решить следующие проблемы, связанные с управлением секретами:

ПроблемыЦели Убежища
Секреты повсюду.Хранилище — единственный источник правды для всех секретов.
Обычно они не зашифрованы.Сейф автоматически управляет шифрованием (во время передачи и хранения).
Их сложно динамически генерировать.Секреты могут генерироваться динамически.
Еще труднее сдать в аренду и отозвать их.Секреты можно сдавать в аренду и отзывать.
Нет никакого контрольного следа.Существует контрольный журнал для создания и использования секретов.

Vault состоит из нескольких движущихся частей, поэтому может потребоваться некоторое время, чтобы привыкнуть к общей архитектуре. Найдите минутку, чтобы просмотреть руководство по архитектуре , приняв во внимание следующие серверные части:

БэкендИспользоватьПримеры
ХранилищеГде хранятся секретыКонсул *, файловая система *, в памяти, PostgreSQL, S3
СекретОбрабатывает статические или динамические секретыAWS *, базы данных, ключ/значение *, RabbitMQ, SSH
АвторизацияОбрабатывает аутентификацию и авторизациюAWS, Azure, Google Cloud, GitHub, токены *, имя пользователя и пароль
АудитРегистрирует все запросы и ответыФайл *, системный журнал, сокет

*используется в этом уроке

Итак, давайте начнем использовать Vault.

Бэкэнд файловой системы

Чтобы быстро приступить к работе, мы будем использовать серверную часть файловой системы для хранения секретов в состоянии покоя.

Серверную часть файловой системы следует использовать только для локальной разработки или развертывания Vault на одном сервере, поскольку она не поддерживает высокую доступность.

Создайте новый каталог проекта:

$ mkdir vault-consul-docker && cd vault-consul-docker

Затем добавьте следующие папки:

└── vault
    ├── config
    ├── data
    ├── logs
    └── policies

Добавьте Dockerfile в каталог «хранилище»:

# base image
FROM alpine:3.14

# set vault version
ENV VAULT_VERSION 1.8.2

# create a new directory
RUN mkdir /vault

# download dependencies
RUN apk --no-cache add \
      bash \
      ca-certificates \
      wget

# download and set up vault
RUN wget --quiet --output-document=/tmp/vault.zip https://releases.hashicorp.com/vault/${VAULT_VERSION}/vault_${VAULT_VERSION}_linux_amd64.zip && \
    unzip /tmp/vault.zip -d /vault && \
    rm -f /tmp/vault.zip && \
    chmod +x /vault

# update PATH
ENV PATH="PATH=$PATH:$PWD/vault"

# add the config file
COPY ./config/vault-config.json /vault/config/vault-config.json

# expose port 8200
EXPOSE 8200

# run vault
ENTRYPOINT ["vault"]

Затем добавьте файл docker-compose.yml в корень проекта:

version: '3.8'

services:

  vault:
    build:
      context: ./vault
      dockerfile: Dockerfile
    ports:
      - 8200:8200
    volumes:
      - ./vault/config:/vault/config
      - ./vault/policies:/vault/policies
      - ./vault/data:/vault/data
      - ./vault/logs:/vault/logs
    environment:
      - VAULT_ADDR=http://127.0.0.1:8200
      - VAULT_API_ADDR=http://127.0.0.1:8200
    command: server -config=/vault/config/vault-config.json
    cap_add:
      - IPC_LOCK

Добавьте файл конфигурации с именем vault-config.json в «vault/config»:

{
  "backend": {
    "file": {
      "path": "vault/data"
    }
  },
  "listener": {
    "tcp":{
      "address": "0.0.0.0:8200",
      "tls_disable": 1
    }
  },
  "ui": true
}

Здесь мы настроили Vault для использования серверной части файловой системы, определили прослушиватель для Vault, отключили TLS и включили пользовательский интерфейс Vault . Ознакомьтесь с документацией для получения дополнительной информации о настройке Vault.

Теперь мы можем создать образ и запустить контейнер:

$ docker-compose up -d --build

Откройте журналы Docker, чтобы убедиться, что в сборке нет ошибок:

$ docker-compose logs

Вы должны увидеть что-то похожее на:

Attaching to vault-consul-docker_vault_1
vault_1  | ==> Vault server configuration:
vault_1  |
vault_1  |              Api Address: http://127.0.0.1:8200
vault_1  | 2021-09-08T14:48:35.014Z [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
vault_1  |                      Cgo: disabled
vault_1  |          Cluster Address: https://127.0.0.1:8201
vault_1  |               Go Version: go1.16.7
vault_1  |               Listener 1: tcp (addr: "0.0.0.0:8200", cluster address: "0.0.0.0:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
vault_1  |                Log Level: info
vault_1  |                    Mlock: supported: true, enabled: true
vault_1  |            Recovery Mode: false
vault_1  |                  Storage: file
vault_1  |                  Version: Vault v1.8.2
vault_1  |              Version Sha: aca76f63357041a43b49f3e8c11d67358496959f
vault_1  |
vault_1  | ==> Vault server started! Log data will stream in below:
vault_1  |

Инициализация и распечатка

Запустите сеанс bash в работающем контейнере:

$ docker-compose exec vault bash

В оболочке инициализируйте Vault:

bash-5.1# vault operator init

Обратите внимание на ключи распечатывания и первоначальный корневой токен. Вам нужно будет предоставлять три ключа распечатывания каждый раз, когда сервер Vault повторно запечатывается или перезапускается.

Почему 3 ключа? Просмотрите секретный обмен Шамира .

Теперь вы можете открыть Хранилище с помощью трех ключей:

bash-5.1# vault operator unseal
Unseal Key (will be hidden):

Запустите эту команду еще два раза, каждый раз используя разные клавиши. После этого убедитесь, Sealedчто false:

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    5
Threshold       3
Version         1.8.2
Storage Type    file
Cluster Name    vault-cluster-8fcf9d05
Cluster ID      d86e0274-ad9c-d2c1-d6ec-baeab410797b
HA Enabled      false

Используя корневой токен, теперь вы можете аутентифицироваться:

bash-5.1# vault login
Token (will be hidden):

Вы должны увидеть что-то похожее на:

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                s.c0kYHWiOTqQvtR8JuSeTz6sZ
token_accessor       3FQJVxOY5C1brzlHHQSFaCdZ
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

Имейте в виду, что при этом используется корневая политика. В рабочей среде вам потребуется настроить политики с разными уровнями доступа. Вскоре мы рассмотрим, как это сделать.

инициализация хранилища

Хранилище теперь распечатано и готово к использованию.

Аудиторская проверка

Прежде чем мы проверим функциональность, давайте включим устройство аудита :

bash-5.1# vault audit enable file file_path=/vault/logs/audit.log

Success! Enabled the file audit device at: file/

Теперь вы сможете просматривать журналы локально в «хранилище/журналах». Для проверки выполните следующую команду, чтобы просмотреть все включенные устройства аудита:

bash-5.1# vault audit list

Path     Type    Description
----     ----    -----------
file/    file    n/a

Запрос и последующий ответ должны регистрироваться в vault/logs/audit.log . Взглянем.

Секреты

В Vault есть два типа секретов: статические и динамические .

Статические секреты (например, зашифрованные Redis или Memcached) имеют интервалы обновления, но срок их действия не истекает, если они не отменены явным образом. Они определяются заранее с помощью бэкэнда Key/Value (ранее «общий» бэкэнд), а затем совместно используются.

надежное секретное хранилище

Динамические секреты генерируются по запросу. Они имеют принудительные договоры аренды и обычно истекают через короткий промежуток времени. Поскольку они не существуют до тех пор, пока к ним не будет осуществлен доступ, они менее уязвимы, поэтому динамические секреты гораздо более безопасны. Vault поставляется с несколькими динамическими бэкендами, например, AWS , Databases , Google Cloud , Consul и RabbitMQ .

Ознакомьтесь с записью блога « Почему нам нужны динамические секреты », чтобы получить дополнительную информацию о преимуществах использования динамических секретов.

Статические секреты

Хранилищем можно управлять через интерфейс командной строки , HTTP API или пользовательский интерфейс .

CLI

Все еще в сеансе bash в контейнере мы можем создавать, читать, обновлять и удалять секреты. Мы также рассмотрим, как создавать версии и откатывать секреты.

Включите секреты с помощью следующей команды:

bash-5.1# vault secrets enable kv

Success! Enabled the kv secrets engine at: kv/

Создайте новый секрет с ключом barи значением preciousвнутри kv/fooпути:

bash-5.1# vault kv put kv/foo bar=precious

Success! Data written to: kv/foo

Читать:

bash-5.1# vault kv get kv/foo

=== Data ===
Key    Value
---    -----
bar    precious

Чтобы работать с разными версиями определенного ключа, нам нужно обновить до версии 2 серверную часть Key/Value :

bash-5.1# vault kv enable-versioning kv/

Success! Tuned the secrets engine at: kv/

Добавьте версию 2, изменив значение на copper:

bash-5.1# vault kv put kv/foo bar=copper

Key              Value
---              -----
created_time     2021-09-08T18:23:14.4154928Z
deletion_time    n/a
destroyed        false
version          2

Читать версию 1:

bash-5.1# vault kv get -version=1 kv/foo

====== Metadata ======
Key              Value
---              -----
created_time     2021-09-08T18:22:37.2548824Z
deletion_time    n/a
destroyed        false
version          1

=== Data ===
Key    Value
---    -----
bar    precious

Читать версию 2:

bash-5.1# vault kv get -version=2 kv/foo

====== Metadata ======
Key              Value
---              -----
created_time     2021-09-08T18:23:14.4154928Z
deletion_time    n/a
destroyed        false
version          2

=== Data ===
Key    Value
---    -----
bar    copper

Удалить последнюю версию (например, версию 2):

bash-5.1# vault kv delete kv/foo

Success! Data deleted (if it existed) at: kv/foo

Удалить версию 1:

bash-5.1# vault kv delete -versions=1 kv/foo

Success! Data deleted (if it existed) at: kv/foo

Вы также можете восстановить:

bash-5.1# vault kv undelete -versions=1 kv/foo

Success! Data written to: kv/undelete/foo

Удаление сродни мягкому удалению. Если вы хотите удалить базовые метаданные, вам придется использовать команду destroy :

bash-5.1# vault kv destroy -versions=1 kv/foo

Success! Data written to: kv/destroy/foo

Просмотрите v1 и v2 , чтобы просмотреть все доступные команды.

Обратите внимание на журнал аудита. Каждый из вышеуказанных запросов был зарегистрирован!

API

Вы также можете взаимодействовать с Vault через HTTP API . Мы будем делать запросы к v2 API. Откройте новую вкладку терминала, а затем установите корневой токен в качестве переменной среды:

$ export VAULT_TOKEN=your_token_goes_here

Создайте новый секрет с именем fooсо значением world:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -H "Content-Type: application/json" \
    -X POST \
    -d '{ "data": { "foo": "world" } }' \
    http://127.0.0.1:8200/v1/kv/data/hello

Прочтите секрет:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -X GET \
    http://127.0.0.1:8200/v1/kv/data/hello

Ответ JSON должен содержать dataключ со значением, подобным:

"data": {
  "data":{
    "foo": "world"
  },
  "metadata": {
    "created_time": "2021-09-08T18:30:32.5140484Z",
    "deletion_time": "",
    "destroyed": false,
    "version": 1
  }
}

API хранилища

Попробуйте добавлять новые версии, удалять и уничтожать самостоятельно.

интерфейс

Пользовательский интерфейс должен работать по адресу http://localhost:8200/ui/vault . Используйте корневой токен для входа. Затем самостоятельно изучите бэкэнд Key/Value:

интерфейс хранилища

Политики

До сих пор мы использовали корневую политику для взаимодействия с API. Давайте настроим политику, которая имеет доступ только для чтения.

Добавьте новый файл конфигурации с именем app-policy.json в «vault/policies»:

{
  "path": {
    "kv/data/app/*": {
      "policy": "read"
    }
  }
}

Создайте новую политику в сеансе bash:

bash-5.1# vault policy write app /vault/policies/app-policy.json

Success! Uploaded policy: app

Затем создайте новый токен:

bash-5.1# vault token create -policy=app

Key                  Value
---                  -----
token                s.ZOUMx3RIhVRhI4ijlZg8KXRQ
token_accessor       TT53xOxbIfGjI7l4392gjXcg
token_duration       768h
token_renewable      true
token_policies       ["app" "default"]
identity_policies    []
policies             ["app" "default"]

На другой новой вкладке терминала (теперь их должно быть три) добавьте VAULT_TOKENпеременную среды с новым токеном:

$ export VAULT_TOKEN=your_token_goes_here

Попробуйте прочитать fooсекрет, который мы установили ранее:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -X GET \
    http://127.0.0.1:8200/v1/kv/data/hello

У вас не должно быть правильных разрешений для просмотра этого секрета:

{
  "errors":[
    "1 error occurred:\n\t* permission denied\n\n"
  ]
}

Почему мы даже не можем это прочитать? Вернитесь к конфигурации политики в vault-config.json . kv/data/app/*указывает, что политика может читать только из appпути.

Как вы, наверное, уже заметили, почти все в Vault основано на путях.

Вернувшись в сеанс bash в контейнере, добавьте новый секрет к app/testпути:

bash-5.1# vault kv put kv/app/test ping=pong

Key              Value
---              -----
created_time     2021-09-08T18:40:35.2694047Z
deletion_time    n/a
destroyed        false
version          1

Вы должны иметь возможность просматривать секрет, используя токен, связанный с appполитикой:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -X GET \
    http://127.0.0.1:8200/v1/kv/data/app/test

Политиками также можно управлять из пользовательского интерфейса:

интерфейс хранилища

Шифрование как услуга

Прежде чем мы рассмотрим динамические секреты, давайте быстро рассмотрим серверную часть Transit , которую можно использовать как «шифрование как услугу» для:

  • Шифрование и дешифрование данных «в пути» без сохранения их в хранилище
  • Простая интеграция шифрования в рабочий процесс вашего приложения

Вернувшись в сеанс bash в контейнере, включите Transit:

bash-5.1# vault secrets enable transit

Success! Enabled the transit secrets engine at: transit/

Настройте именованный ключ шифрования:

bash-5.1# vault write -f transit/keys/foo

Success! Data written to: transit/keys/foo

Зашифровать:

bash-5.1# vault write transit/encrypt/foo plaintext=$(base64 <<< "my precious")

Key           Value
---           -----
ciphertext    vault:v1:cFnk5AQLE9Mg+mZ7Ej17vRmYT5aqheikdZQ1FC4vre5jAod0L/uHDA==

Расшифровать:

bash-5.1# vault write transit/decrypt/foo ciphertext=vault:v1:cFnk5AQLE9Mg+mZ7Ej17vRmYT5aqheikdZQ1FC4vre5jAod0L/uHDA==

Key          Value
---          -----
plaintext    bXkgcHJlY2lvdXMK

Расшифровать:

bash-5.1# base64 -d <<< "bXkgcHJlY2lvdXMK"

my precious

Проверьте это и в пользовательском интерфейсе:

интерфейс хранилища

Динамические секреты

Как уже упоминалось, Vault поддерживает ряд динамических секретных бэкэндов для динамического создания секретов при необходимости. Например, с помощью серверных частей AWS и Google Cloud вы можете создавать учетные данные для доступа на основе политик IAM. Тем временем серверная часть баз данных генерирует учетные данные базы данных на основе настроенных ролей .

Динамические секреты:

  • генерируются по запросу
  • иметь ограниченный доступ в зависимости от роли
  • сдаются в аренду на срок
  • может быть отозван
  • прийти с аудиторским следом

Давайте посмотрим, как сгенерировать учетные данные AWS с помощью серверной части AWS.

Учетные данные AWS

Включите серверную часть секретов AWS:

bash-5.1# vault secrets enable -path=aws aws

Success! Enabled the aws secrets engine at: aws/

Аутентификация:

bash-5.1# vault write aws/config/root access_key=foo secret_key=bar

Success! Data written to: aws/config/root

Обязательно замените fooи barна идентификатор ключа доступа AWS и секретный ключ соответственно.

Создать роль:

bash-5.1# vault write aws/roles/ec2-read credential_type=iam_user policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
EOF

Success! Data written to: aws/roles/ec2-read

Здесь мы создали новую роль на основе политикиAmazonEC2ReadOnlyAccess , управляемой AWS . Как следует из названия, он предоставляет пользователям доступ только для чтения к консоли EC2; они не могут выполнять какие-либо действия или создавать новые ресурсы. Вы также можете использовать встроенную политику для создания пользовательской роли в соответствии с вашими индивидуальными потребностями. Вскоре мы рассмотрим это на примере. Дополнительную информацию см . в документации AWS Secrets Engine .

Помните : динамические секреты генерируются только тогда, когда они запрашиваются (например, веб-приложение запрашивает доступ к S3). До этого в магазине их нет.

Создайте новый набор учетных данных:

bash-5.1# vault read aws/creds/ec2-read

Key                Value
---                -----
lease_id           aws/creds/ec2-read/9KdO6J7KVBiSwOPEvwrqqALG
lease_duration     768h
lease_renewable    true
access_key         AKIAZ4DZAKZKEULSDW5A
secret_key         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
security_token     <nil>

Теперь вы должны увидеть пользователя в разделе «Пользователи» на консоли IAM на AWS:

Мне жаль

Аренда и отзыв

В этом разделе мы кратко рассмотрим, как определить пользовательский период аренды и отозвать секрет до окончания этого периода.

Создайте новую роль AWS:

bash-5.1# vault write aws/roles/foo credential_type=iam_user policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
EOF

Success! Data written to: aws/roles/foo

Обратите внимание на то, что lease_durationпри создании новых учетных данных AWS:

bash-5.1# vault read aws/creds/foo

Key                Value
---                -----
lease_id           aws/creds/foo/F0oBbnBIHEoz0ywVVtbuJB7r
lease_duration     768h
lease_renewable    true
access_key         AKIAZ4DZAKZKLJKB7CPX
secret_key         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
security_token     <nil>

Что, если вы хотите, чтобы период аренды для всех динамических секретов AWS IAM составлял 30 минут?

bash-5.1# vault write aws/config/lease lease=1800s lease_max=1800s

В этом примере, поскольку lease_maxэто то же самое lease, что и , вы не сможете обновить токен. Если вы установите значение lease_max, 3600sвы сможете продлить аренду один раз. Для получения дополнительной информации ознакомьтесь с руководством по токенам и аренде .

Создайте новые учетные данные:

bash-5.1# vault read aws/creds/foo

Key                Value
---                -----
lease_id           aws/creds/foo/xQlJpKDS1ljE9Awz0aywXgbB
lease_duration     30m
lease_renewable    true
access_key         AKIAZ4DZAKZKJPL5OM5W
secret_key         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
security_token     <nil>

Хотите быстро отозвать эти учетные данные? Возьмите, lease_idа затем запустите:

bash-5.1# vault lease revoke aws/creds/foo/xQlJpKDS1ljE9Awz0aywXgbB

Хотите отозвать все кредиты AWS?

bash-5.1# vault lease revoke -prefix aws/

Дополнительные сведения об этих концепциях см. в руководстве по аренде, продлению и отзыву .

Консул Бэкэнд

До сих пор мы использовали серверную часть файловой системы . Он не будет масштабироваться за пределы одного сервера, поэтому он не использует преимущества высокой доступности Vault. К счастью, существует ряд других бэкендов Storage , таких как бэкенд Consul , предназначенных для распределенных систем.

Чтобы настроить Consul , начните с обновления файла docker-compose.yml :

version: '3.8'

services:

  vault:
    build:
      context: ./vault
      dockerfile: Dockerfile
    ports:
      - 8200:8200
    volumes:
      - ./vault/config:/vault/config
      - ./vault/policies:/vault/policies
      - ./vault/data:/vault/data
      - ./vault/logs:/vault/logs
    environment:
      - VAULT_ADDR=http://127.0.0.1:8200
      - VAULT_API_ADDR=http://127.0.0.1:8200
    command: server -config=/vault/config/vault-config.json
    cap_add:
      - IPC_LOCK
    depends_on:
      - consul

  consul:
    build:
      context: ./consul
      dockerfile: Dockerfile
    ports:
      - 8500:8500
    command: agent -server -bind 0.0.0.0 -client 0.0.0.0 -bootstrap-expect 1 -config-file=/consul/config/config.json
    volumes:
      - ./consul/config/consul-config.json:/consul/config/config.json
      - ./consul/data:/consul/data

Добавьте новый каталог в корень проекта с именем «consul», а затем добавьте новый Dockerfile в этот вновь созданный каталог:

# base image
FROM alpine:3.14

# set consul version
ENV CONSUL_VERSION 1.10.2

# create a new directory
RUN mkdir /consul

# download dependencies
RUN apk --no-cache add \
      bash \
      ca-certificates \
      wget

# download and set up consul
RUN wget --quiet --output-document=/tmp/consul.zip https://releases.hashicorp.com/consul/${CONSUL_VERSION}/consul_${CONSUL_VERSION}_linux_amd64.zip && \
    unzip /tmp/consul.zip -d /consul && \
    rm -f /tmp/consul.zip && \
    chmod +x /consul/consul

# update PATH
ENV PATH="PATH=$PATH:$PWD/consul"

# add the config file
COPY ./config/consul-config.json /consul/config/config.json

# expose ports
EXPOSE 8300 8400 8500 8600

# run consul
ENTRYPOINT ["consul"]

Затем в каталоге «consul» добавьте два новых каталога: «config» и «data». Затем в «config» добавьте файл конфигурации с именем consul-config.json :

{
  "datacenter": "localhost",
  "data_dir": "/consul/data",
  "log_level": "DEBUG",
  "server": true,
  "ui": true,
  "ports": {
    "dns": 53
  }
}

Обязательно ознакомьтесь с параметрами конфигурации из документов Consul для получения дополнительной информации о вышеуказанных параметрах.

Теперь каталог «consul» должен выглядеть так:

├── Dockerfile
├── config
│   └── consul-config.json
└── data

Выйдите из сеанса bash. Перенесите контейнер, а затем обновите файл конфигурации Vault:

{
  "backend": {
    "consul": {
      "address": "consul:8500",
      "path": "vault/"
    }
  },
  "listener": {
    "tcp":{
      "address": "0.0.0.0:8200",
      "tls_disable": 1
    }
  },
  "ui": true
}

Итак, теперь мы используем бэкенд Consul вместо файловой системы. Мы использовали название службы consulкак часть адреса. Ключ определяет путь pathв хранилище ключей/значений Consul, где будут храниться данные Vault.

Очистите все файлы и папки в каталоге «vault/data», чтобы удалить серверную часть файловой системы. Создайте новые образы и разверните контейнеры:

$ docker-compose down
$ docker-compose up -d --build

Убедитесь, что все в порядке, перейдя в браузере по адресу http://localhost:8500/ui :

консул пользовательского интерфейса

Проверьте это из интерфейса командной строки или пользовательского интерфейса.

CLI

Создайте новую сессию bash в контейнере Vault:

$ docker-compose exec vault bash

Затем запустите:

# Init
bash-5.1# vault operator init

# Unseal
bash-5.1# vault operator unseal

# Authenticate
bash-5.1# vault login

# Enable secrets
bash-5.1# vault secrets enable kv

# Add a new static secret
bash-5.1# vault kv put kv/foo bar=precious

# Read it back
bash-5.1# vault kv get kv/foo

интерфейс

консул хранилища

Обратите внимание, что в «хранилище/данных» нет файлов или папок. Как вы думаете, почему это так?

Хотите добавить еще один сервер Consul? Добавьте новый сервис в docker-compose.yml :

consul-worker:
  build:
    context: ./consul
    dockerfile: Dockerfile
  command: agent -server -join consul -config-file=/consul/config/config.json
  volumes:
    - ./consul/config/consul-config.json:/consul/config/config.json
  depends_on:
    - consul

Здесь мы использовали команду join для подключения этого агента к существующему кластеру. Обратите внимание, что нам просто нужно было сослаться на имя службы: consul.

Затем:

  1. Выход из bash-сессии (при необходимости)
  2. Снести контейнеры
  3. Очистите каталог данных в «consul/data» (почему?)
  4. Вращайте контейнеры обратно и проверяйте

консул пользовательского интерфейса

Вывод

В этом руководстве мы рассмотрели, как настроить и запустить Vault и Consul внутри контейнера Docker. Теперь у вас должно быть четкое представление о том, как взаимодействовать с Vault и выполнять основные операции.

Возьмите окончательный код из репозитория vault-consul-docker . Ознакомьтесь также с презентацией .

Источник:  https://testdriven.io

#vault #consul 

What is GEEK

Buddha Community

Как настроить и использовать проекты Hashicorp Vault и Consul

Как настроить и использовать проекты Hashicorp Vault и Consul

В следующем руководстве подробно описано, как настроить и использовать проекты Hashicorp Vault и Consul для безопасного хранения секретов и управления ими.

Мы начнем с запуска одного экземпляра Vault в контейнере Docker, а затем перейдем к управлению как статическими, так и динамическими секретами вместе с функцией Vault «шифрование как услуга». Затем мы добавим Consul и посмотрим, как масштабировать Vault.

Основные зависимости:

  • Докер v20.10.8
  • Докер-композитор v1.29.2
  • Убежище v1.8.2
  • Консул v1.10.2

Цели

К концу этого урока вы должны уметь:

  1. Объясните, что такое Vault и почему вы можете захотеть его использовать.
  2. Описать базовую архитектуру Vault, а также динамические и статические секреты, различные серверные части (хранилище, секрет, аутентификация, аудит) и то, как Vault можно использовать в качестве «шифрования как услуги».
  3. Настройте и запустите Vault и Consul с помощью Docker
  4. Раскрутите Vault с помощью серверной части файловой системы
  5. Инициализировать и распечатать хранилище
  6. Аутентификация в хранилище
  7. Настройте серверную часть аудита для регистрации всех взаимодействий с Vault.
  8. Работайте со статическими и динамическими секретами через интерфейс командной строки, HTTP API и пользовательский интерфейс.
  9. Создайте политику Vault, чтобы ограничить доступ к определенному пути
  10. Используйте серверную часть Transit как «шифрование как услугу».
  11. Настройте Consul для работы с Vault в качестве хранилища для секретов.
  12. Определите пользовательский период аренды для секрета и отзовите секрет до окончания этого периода.

Что такое Сейф?

Vault — это инструмент с открытым исходным кодом, используемый для безопасного хранения секретов и управления ими.

Что такое секрет? Секреты в контексте этого руководства — это конфиденциальная или личная информация, такая как учетные данные базы данных, ключи SSH, имена пользователей и пароли, учетные данные AWS IAM, токены API, номера социального страхования, номера кредитных карт и т. д.

Найдите минутку, чтобы подумать о том, как ваша команда в настоящее время управляет секретами и распределяет их:

  1. Кто имеет к ним доступ?
  2. Кто ими управляет?
  3. Как вы контролируете, кто имеет к ним доступ?
  4. Как ваши приложения получают их?
  5. Как они обновляются?
  6. Как они отзываются?

Vault дает ответы на эти вопросы и помогает решить следующие проблемы, связанные с управлением секретами:

ПроблемыЦели Убежища
Секреты повсюду.Хранилище — единственный источник правды для всех секретов.
Обычно они не зашифрованы.Сейф автоматически управляет шифрованием (во время передачи и хранения).
Их сложно динамически генерировать.Секреты могут генерироваться динамически.
Еще труднее сдать в аренду и отозвать их.Секреты можно сдавать в аренду и отзывать.
Нет никакого контрольного следа.Существует контрольный журнал для создания и использования секретов.

Vault состоит из нескольких движущихся частей, поэтому может потребоваться некоторое время, чтобы привыкнуть к общей архитектуре. Найдите минутку, чтобы просмотреть руководство по архитектуре , приняв во внимание следующие серверные части:

БэкендИспользоватьПримеры
ХранилищеГде хранятся секретыКонсул *, файловая система *, в памяти, PostgreSQL, S3
СекретОбрабатывает статические или динамические секретыAWS *, базы данных, ключ/значение *, RabbitMQ, SSH
АвторизацияОбрабатывает аутентификацию и авторизациюAWS, Azure, Google Cloud, GitHub, токены *, имя пользователя и пароль
АудитРегистрирует все запросы и ответыФайл *, системный журнал, сокет

*используется в этом уроке

Итак, давайте начнем использовать Vault.

Бэкэнд файловой системы

Чтобы быстро приступить к работе, мы будем использовать серверную часть файловой системы для хранения секретов в состоянии покоя.

Серверную часть файловой системы следует использовать только для локальной разработки или развертывания Vault на одном сервере, поскольку она не поддерживает высокую доступность.

Создайте новый каталог проекта:

$ mkdir vault-consul-docker && cd vault-consul-docker

Затем добавьте следующие папки:

└── vault
    ├── config
    ├── data
    ├── logs
    └── policies

Добавьте Dockerfile в каталог «хранилище»:

# base image
FROM alpine:3.14

# set vault version
ENV VAULT_VERSION 1.8.2

# create a new directory
RUN mkdir /vault

# download dependencies
RUN apk --no-cache add \
      bash \
      ca-certificates \
      wget

# download and set up vault
RUN wget --quiet --output-document=/tmp/vault.zip https://releases.hashicorp.com/vault/${VAULT_VERSION}/vault_${VAULT_VERSION}_linux_amd64.zip && \
    unzip /tmp/vault.zip -d /vault && \
    rm -f /tmp/vault.zip && \
    chmod +x /vault

# update PATH
ENV PATH="PATH=$PATH:$PWD/vault"

# add the config file
COPY ./config/vault-config.json /vault/config/vault-config.json

# expose port 8200
EXPOSE 8200

# run vault
ENTRYPOINT ["vault"]

Затем добавьте файл docker-compose.yml в корень проекта:

version: '3.8'

services:

  vault:
    build:
      context: ./vault
      dockerfile: Dockerfile
    ports:
      - 8200:8200
    volumes:
      - ./vault/config:/vault/config
      - ./vault/policies:/vault/policies
      - ./vault/data:/vault/data
      - ./vault/logs:/vault/logs
    environment:
      - VAULT_ADDR=http://127.0.0.1:8200
      - VAULT_API_ADDR=http://127.0.0.1:8200
    command: server -config=/vault/config/vault-config.json
    cap_add:
      - IPC_LOCK

Добавьте файл конфигурации с именем vault-config.json в «vault/config»:

{
  "backend": {
    "file": {
      "path": "vault/data"
    }
  },
  "listener": {
    "tcp":{
      "address": "0.0.0.0:8200",
      "tls_disable": 1
    }
  },
  "ui": true
}

Здесь мы настроили Vault для использования серверной части файловой системы, определили прослушиватель для Vault, отключили TLS и включили пользовательский интерфейс Vault . Ознакомьтесь с документацией для получения дополнительной информации о настройке Vault.

Теперь мы можем создать образ и запустить контейнер:

$ docker-compose up -d --build

Откройте журналы Docker, чтобы убедиться, что в сборке нет ошибок:

$ docker-compose logs

Вы должны увидеть что-то похожее на:

Attaching to vault-consul-docker_vault_1
vault_1  | ==> Vault server configuration:
vault_1  |
vault_1  |              Api Address: http://127.0.0.1:8200
vault_1  | 2021-09-08T14:48:35.014Z [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
vault_1  |                      Cgo: disabled
vault_1  |          Cluster Address: https://127.0.0.1:8201
vault_1  |               Go Version: go1.16.7
vault_1  |               Listener 1: tcp (addr: "0.0.0.0:8200", cluster address: "0.0.0.0:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
vault_1  |                Log Level: info
vault_1  |                    Mlock: supported: true, enabled: true
vault_1  |            Recovery Mode: false
vault_1  |                  Storage: file
vault_1  |                  Version: Vault v1.8.2
vault_1  |              Version Sha: aca76f63357041a43b49f3e8c11d67358496959f
vault_1  |
vault_1  | ==> Vault server started! Log data will stream in below:
vault_1  |

Инициализация и распечатка

Запустите сеанс bash в работающем контейнере:

$ docker-compose exec vault bash

В оболочке инициализируйте Vault:

bash-5.1# vault operator init

Обратите внимание на ключи распечатывания и первоначальный корневой токен. Вам нужно будет предоставлять три ключа распечатывания каждый раз, когда сервер Vault повторно запечатывается или перезапускается.

Почему 3 ключа? Просмотрите секретный обмен Шамира .

Теперь вы можете открыть Хранилище с помощью трех ключей:

bash-5.1# vault operator unseal
Unseal Key (will be hidden):

Запустите эту команду еще два раза, каждый раз используя разные клавиши. После этого убедитесь, Sealedчто false:

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    5
Threshold       3
Version         1.8.2
Storage Type    file
Cluster Name    vault-cluster-8fcf9d05
Cluster ID      d86e0274-ad9c-d2c1-d6ec-baeab410797b
HA Enabled      false

Используя корневой токен, теперь вы можете аутентифицироваться:

bash-5.1# vault login
Token (will be hidden):

Вы должны увидеть что-то похожее на:

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                s.c0kYHWiOTqQvtR8JuSeTz6sZ
token_accessor       3FQJVxOY5C1brzlHHQSFaCdZ
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

Имейте в виду, что при этом используется корневая политика. В рабочей среде вам потребуется настроить политики с разными уровнями доступа. Вскоре мы рассмотрим, как это сделать.

инициализация хранилища

Хранилище теперь распечатано и готово к использованию.

Аудиторская проверка

Прежде чем мы проверим функциональность, давайте включим устройство аудита :

bash-5.1# vault audit enable file file_path=/vault/logs/audit.log

Success! Enabled the file audit device at: file/

Теперь вы сможете просматривать журналы локально в «хранилище/журналах». Для проверки выполните следующую команду, чтобы просмотреть все включенные устройства аудита:

bash-5.1# vault audit list

Path     Type    Description
----     ----    -----------
file/    file    n/a

Запрос и последующий ответ должны регистрироваться в vault/logs/audit.log . Взглянем.

Секреты

В Vault есть два типа секретов: статические и динамические .

Статические секреты (например, зашифрованные Redis или Memcached) имеют интервалы обновления, но срок их действия не истекает, если они не отменены явным образом. Они определяются заранее с помощью бэкэнда Key/Value (ранее «общий» бэкэнд), а затем совместно используются.

надежное секретное хранилище

Динамические секреты генерируются по запросу. Они имеют принудительные договоры аренды и обычно истекают через короткий промежуток времени. Поскольку они не существуют до тех пор, пока к ним не будет осуществлен доступ, они менее уязвимы, поэтому динамические секреты гораздо более безопасны. Vault поставляется с несколькими динамическими бэкендами, например, AWS , Databases , Google Cloud , Consul и RabbitMQ .

Ознакомьтесь с записью блога « Почему нам нужны динамические секреты », чтобы получить дополнительную информацию о преимуществах использования динамических секретов.

Статические секреты

Хранилищем можно управлять через интерфейс командной строки , HTTP API или пользовательский интерфейс .

CLI

Все еще в сеансе bash в контейнере мы можем создавать, читать, обновлять и удалять секреты. Мы также рассмотрим, как создавать версии и откатывать секреты.

Включите секреты с помощью следующей команды:

bash-5.1# vault secrets enable kv

Success! Enabled the kv secrets engine at: kv/

Создайте новый секрет с ключом barи значением preciousвнутри kv/fooпути:

bash-5.1# vault kv put kv/foo bar=precious

Success! Data written to: kv/foo

Читать:

bash-5.1# vault kv get kv/foo

=== Data ===
Key    Value
---    -----
bar    precious

Чтобы работать с разными версиями определенного ключа, нам нужно обновить до версии 2 серверную часть Key/Value :

bash-5.1# vault kv enable-versioning kv/

Success! Tuned the secrets engine at: kv/

Добавьте версию 2, изменив значение на copper:

bash-5.1# vault kv put kv/foo bar=copper

Key              Value
---              -----
created_time     2021-09-08T18:23:14.4154928Z
deletion_time    n/a
destroyed        false
version          2

Читать версию 1:

bash-5.1# vault kv get -version=1 kv/foo

====== Metadata ======
Key              Value
---              -----
created_time     2021-09-08T18:22:37.2548824Z
deletion_time    n/a
destroyed        false
version          1

=== Data ===
Key    Value
---    -----
bar    precious

Читать версию 2:

bash-5.1# vault kv get -version=2 kv/foo

====== Metadata ======
Key              Value
---              -----
created_time     2021-09-08T18:23:14.4154928Z
deletion_time    n/a
destroyed        false
version          2

=== Data ===
Key    Value
---    -----
bar    copper

Удалить последнюю версию (например, версию 2):

bash-5.1# vault kv delete kv/foo

Success! Data deleted (if it existed) at: kv/foo

Удалить версию 1:

bash-5.1# vault kv delete -versions=1 kv/foo

Success! Data deleted (if it existed) at: kv/foo

Вы также можете восстановить:

bash-5.1# vault kv undelete -versions=1 kv/foo

Success! Data written to: kv/undelete/foo

Удаление сродни мягкому удалению. Если вы хотите удалить базовые метаданные, вам придется использовать команду destroy :

bash-5.1# vault kv destroy -versions=1 kv/foo

Success! Data written to: kv/destroy/foo

Просмотрите v1 и v2 , чтобы просмотреть все доступные команды.

Обратите внимание на журнал аудита. Каждый из вышеуказанных запросов был зарегистрирован!

API

Вы также можете взаимодействовать с Vault через HTTP API . Мы будем делать запросы к v2 API. Откройте новую вкладку терминала, а затем установите корневой токен в качестве переменной среды:

$ export VAULT_TOKEN=your_token_goes_here

Создайте новый секрет с именем fooсо значением world:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -H "Content-Type: application/json" \
    -X POST \
    -d '{ "data": { "foo": "world" } }' \
    http://127.0.0.1:8200/v1/kv/data/hello

Прочтите секрет:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -X GET \
    http://127.0.0.1:8200/v1/kv/data/hello

Ответ JSON должен содержать dataключ со значением, подобным:

"data": {
  "data":{
    "foo": "world"
  },
  "metadata": {
    "created_time": "2021-09-08T18:30:32.5140484Z",
    "deletion_time": "",
    "destroyed": false,
    "version": 1
  }
}

API хранилища

Попробуйте добавлять новые версии, удалять и уничтожать самостоятельно.

интерфейс

Пользовательский интерфейс должен работать по адресу http://localhost:8200/ui/vault . Используйте корневой токен для входа. Затем самостоятельно изучите бэкэнд Key/Value:

интерфейс хранилища

Политики

До сих пор мы использовали корневую политику для взаимодействия с API. Давайте настроим политику, которая имеет доступ только для чтения.

Добавьте новый файл конфигурации с именем app-policy.json в «vault/policies»:

{
  "path": {
    "kv/data/app/*": {
      "policy": "read"
    }
  }
}

Создайте новую политику в сеансе bash:

bash-5.1# vault policy write app /vault/policies/app-policy.json

Success! Uploaded policy: app

Затем создайте новый токен:

bash-5.1# vault token create -policy=app

Key                  Value
---                  -----
token                s.ZOUMx3RIhVRhI4ijlZg8KXRQ
token_accessor       TT53xOxbIfGjI7l4392gjXcg
token_duration       768h
token_renewable      true
token_policies       ["app" "default"]
identity_policies    []
policies             ["app" "default"]

На другой новой вкладке терминала (теперь их должно быть три) добавьте VAULT_TOKENпеременную среды с новым токеном:

$ export VAULT_TOKEN=your_token_goes_here

Попробуйте прочитать fooсекрет, который мы установили ранее:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -X GET \
    http://127.0.0.1:8200/v1/kv/data/hello

У вас не должно быть правильных разрешений для просмотра этого секрета:

{
  "errors":[
    "1 error occurred:\n\t* permission denied\n\n"
  ]
}

Почему мы даже не можем это прочитать? Вернитесь к конфигурации политики в vault-config.json . kv/data/app/*указывает, что политика может читать только из appпути.

Как вы, наверное, уже заметили, почти все в Vault основано на путях.

Вернувшись в сеанс bash в контейнере, добавьте новый секрет к app/testпути:

bash-5.1# vault kv put kv/app/test ping=pong

Key              Value
---              -----
created_time     2021-09-08T18:40:35.2694047Z
deletion_time    n/a
destroyed        false
version          1

Вы должны иметь возможность просматривать секрет, используя токен, связанный с appполитикой:

$ curl \
    -H "X-Vault-Token: $VAULT_TOKEN" \
    -X GET \
    http://127.0.0.1:8200/v1/kv/data/app/test

Политиками также можно управлять из пользовательского интерфейса:

интерфейс хранилища

Шифрование как услуга

Прежде чем мы рассмотрим динамические секреты, давайте быстро рассмотрим серверную часть Transit , которую можно использовать как «шифрование как услугу» для:

  • Шифрование и дешифрование данных «в пути» без сохранения их в хранилище
  • Простая интеграция шифрования в рабочий процесс вашего приложения

Вернувшись в сеанс bash в контейнере, включите Transit:

bash-5.1# vault secrets enable transit

Success! Enabled the transit secrets engine at: transit/

Настройте именованный ключ шифрования:

bash-5.1# vault write -f transit/keys/foo

Success! Data written to: transit/keys/foo

Зашифровать:

bash-5.1# vault write transit/encrypt/foo plaintext=$(base64 <<< "my precious")

Key           Value
---           -----
ciphertext    vault:v1:cFnk5AQLE9Mg+mZ7Ej17vRmYT5aqheikdZQ1FC4vre5jAod0L/uHDA==

Расшифровать:

bash-5.1# vault write transit/decrypt/foo ciphertext=vault:v1:cFnk5AQLE9Mg+mZ7Ej17vRmYT5aqheikdZQ1FC4vre5jAod0L/uHDA==

Key          Value
---          -----
plaintext    bXkgcHJlY2lvdXMK

Расшифровать:

bash-5.1# base64 -d <<< "bXkgcHJlY2lvdXMK"

my precious

Проверьте это и в пользовательском интерфейсе:

интерфейс хранилища

Динамические секреты

Как уже упоминалось, Vault поддерживает ряд динамических секретных бэкэндов для динамического создания секретов при необходимости. Например, с помощью серверных частей AWS и Google Cloud вы можете создавать учетные данные для доступа на основе политик IAM. Тем временем серверная часть баз данных генерирует учетные данные базы данных на основе настроенных ролей .

Динамические секреты:

  • генерируются по запросу
  • иметь ограниченный доступ в зависимости от роли
  • сдаются в аренду на срок
  • может быть отозван
  • прийти с аудиторским следом

Давайте посмотрим, как сгенерировать учетные данные AWS с помощью серверной части AWS.

Учетные данные AWS

Включите серверную часть секретов AWS:

bash-5.1# vault secrets enable -path=aws aws

Success! Enabled the aws secrets engine at: aws/

Аутентификация:

bash-5.1# vault write aws/config/root access_key=foo secret_key=bar

Success! Data written to: aws/config/root

Обязательно замените fooи barна идентификатор ключа доступа AWS и секретный ключ соответственно.

Создать роль:

bash-5.1# vault write aws/roles/ec2-read credential_type=iam_user policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
EOF

Success! Data written to: aws/roles/ec2-read

Здесь мы создали новую роль на основе политикиAmazonEC2ReadOnlyAccess , управляемой AWS . Как следует из названия, он предоставляет пользователям доступ только для чтения к консоли EC2; они не могут выполнять какие-либо действия или создавать новые ресурсы. Вы также можете использовать встроенную политику для создания пользовательской роли в соответствии с вашими индивидуальными потребностями. Вскоре мы рассмотрим это на примере. Дополнительную информацию см . в документации AWS Secrets Engine .

Помните : динамические секреты генерируются только тогда, когда они запрашиваются (например, веб-приложение запрашивает доступ к S3). До этого в магазине их нет.

Создайте новый набор учетных данных:

bash-5.1# vault read aws/creds/ec2-read

Key                Value
---                -----
lease_id           aws/creds/ec2-read/9KdO6J7KVBiSwOPEvwrqqALG
lease_duration     768h
lease_renewable    true
access_key         AKIAZ4DZAKZKEULSDW5A
secret_key         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
security_token     <nil>

Теперь вы должны увидеть пользователя в разделе «Пользователи» на консоли IAM на AWS:

Мне жаль

Аренда и отзыв

В этом разделе мы кратко рассмотрим, как определить пользовательский период аренды и отозвать секрет до окончания этого периода.

Создайте новую роль AWS:

bash-5.1# vault write aws/roles/foo credential_type=iam_user policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
EOF

Success! Data written to: aws/roles/foo

Обратите внимание на то, что lease_durationпри создании новых учетных данных AWS:

bash-5.1# vault read aws/creds/foo

Key                Value
---                -----
lease_id           aws/creds/foo/F0oBbnBIHEoz0ywVVtbuJB7r
lease_duration     768h
lease_renewable    true
access_key         AKIAZ4DZAKZKLJKB7CPX
secret_key         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
security_token     <nil>

Что, если вы хотите, чтобы период аренды для всех динамических секретов AWS IAM составлял 30 минут?

bash-5.1# vault write aws/config/lease lease=1800s lease_max=1800s

В этом примере, поскольку lease_maxэто то же самое lease, что и , вы не сможете обновить токен. Если вы установите значение lease_max, 3600sвы сможете продлить аренду один раз. Для получения дополнительной информации ознакомьтесь с руководством по токенам и аренде .

Создайте новые учетные данные:

bash-5.1# vault read aws/creds/foo

Key                Value
---                -----
lease_id           aws/creds/foo/xQlJpKDS1ljE9Awz0aywXgbB
lease_duration     30m
lease_renewable    true
access_key         AKIAZ4DZAKZKJPL5OM5W
secret_key         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
security_token     <nil>

Хотите быстро отозвать эти учетные данные? Возьмите, lease_idа затем запустите:

bash-5.1# vault lease revoke aws/creds/foo/xQlJpKDS1ljE9Awz0aywXgbB

Хотите отозвать все кредиты AWS?

bash-5.1# vault lease revoke -prefix aws/

Дополнительные сведения об этих концепциях см. в руководстве по аренде, продлению и отзыву .

Консул Бэкэнд

До сих пор мы использовали серверную часть файловой системы . Он не будет масштабироваться за пределы одного сервера, поэтому он не использует преимущества высокой доступности Vault. К счастью, существует ряд других бэкендов Storage , таких как бэкенд Consul , предназначенных для распределенных систем.

Чтобы настроить Consul , начните с обновления файла docker-compose.yml :

version: '3.8'

services:

  vault:
    build:
      context: ./vault
      dockerfile: Dockerfile
    ports:
      - 8200:8200
    volumes:
      - ./vault/config:/vault/config
      - ./vault/policies:/vault/policies
      - ./vault/data:/vault/data
      - ./vault/logs:/vault/logs
    environment:
      - VAULT_ADDR=http://127.0.0.1:8200
      - VAULT_API_ADDR=http://127.0.0.1:8200
    command: server -config=/vault/config/vault-config.json
    cap_add:
      - IPC_LOCK
    depends_on:
      - consul

  consul:
    build:
      context: ./consul
      dockerfile: Dockerfile
    ports:
      - 8500:8500
    command: agent -server -bind 0.0.0.0 -client 0.0.0.0 -bootstrap-expect 1 -config-file=/consul/config/config.json
    volumes:
      - ./consul/config/consul-config.json:/consul/config/config.json
      - ./consul/data:/consul/data

Добавьте новый каталог в корень проекта с именем «consul», а затем добавьте новый Dockerfile в этот вновь созданный каталог:

# base image
FROM alpine:3.14

# set consul version
ENV CONSUL_VERSION 1.10.2

# create a new directory
RUN mkdir /consul

# download dependencies
RUN apk --no-cache add \
      bash \
      ca-certificates \
      wget

# download and set up consul
RUN wget --quiet --output-document=/tmp/consul.zip https://releases.hashicorp.com/consul/${CONSUL_VERSION}/consul_${CONSUL_VERSION}_linux_amd64.zip && \
    unzip /tmp/consul.zip -d /consul && \
    rm -f /tmp/consul.zip && \
    chmod +x /consul/consul

# update PATH
ENV PATH="PATH=$PATH:$PWD/consul"

# add the config file
COPY ./config/consul-config.json /consul/config/config.json

# expose ports
EXPOSE 8300 8400 8500 8600

# run consul
ENTRYPOINT ["consul"]

Затем в каталоге «consul» добавьте два новых каталога: «config» и «data». Затем в «config» добавьте файл конфигурации с именем consul-config.json :

{
  "datacenter": "localhost",
  "data_dir": "/consul/data",
  "log_level": "DEBUG",
  "server": true,
  "ui": true,
  "ports": {
    "dns": 53
  }
}

Обязательно ознакомьтесь с параметрами конфигурации из документов Consul для получения дополнительной информации о вышеуказанных параметрах.

Теперь каталог «consul» должен выглядеть так:

├── Dockerfile
├── config
│   └── consul-config.json
└── data

Выйдите из сеанса bash. Перенесите контейнер, а затем обновите файл конфигурации Vault:

{
  "backend": {
    "consul": {
      "address": "consul:8500",
      "path": "vault/"
    }
  },
  "listener": {
    "tcp":{
      "address": "0.0.0.0:8200",
      "tls_disable": 1
    }
  },
  "ui": true
}

Итак, теперь мы используем бэкенд Consul вместо файловой системы. Мы использовали название службы consulкак часть адреса. Ключ определяет путь pathв хранилище ключей/значений Consul, где будут храниться данные Vault.

Очистите все файлы и папки в каталоге «vault/data», чтобы удалить серверную часть файловой системы. Создайте новые образы и разверните контейнеры:

$ docker-compose down
$ docker-compose up -d --build

Убедитесь, что все в порядке, перейдя в браузере по адресу http://localhost:8500/ui :

консул пользовательского интерфейса

Проверьте это из интерфейса командной строки или пользовательского интерфейса.

CLI

Создайте новую сессию bash в контейнере Vault:

$ docker-compose exec vault bash

Затем запустите:

# Init
bash-5.1# vault operator init

# Unseal
bash-5.1# vault operator unseal

# Authenticate
bash-5.1# vault login

# Enable secrets
bash-5.1# vault secrets enable kv

# Add a new static secret
bash-5.1# vault kv put kv/foo bar=precious

# Read it back
bash-5.1# vault kv get kv/foo

интерфейс

консул хранилища

Обратите внимание, что в «хранилище/данных» нет файлов или папок. Как вы думаете, почему это так?

Хотите добавить еще один сервер Consul? Добавьте новый сервис в docker-compose.yml :

consul-worker:
  build:
    context: ./consul
    dockerfile: Dockerfile
  command: agent -server -join consul -config-file=/consul/config/config.json
  volumes:
    - ./consul/config/consul-config.json:/consul/config/config.json
  depends_on:
    - consul

Здесь мы использовали команду join для подключения этого агента к существующему кластеру. Обратите внимание, что нам просто нужно было сослаться на имя службы: consul.

Затем:

  1. Выход из bash-сессии (при необходимости)
  2. Снести контейнеры
  3. Очистите каталог данных в «consul/data» (почему?)
  4. Вращайте контейнеры обратно и проверяйте

консул пользовательского интерфейса

Вывод

В этом руководстве мы рассмотрели, как настроить и запустить Vault и Consul внутри контейнера Docker. Теперь у вас должно быть четкое представление о том, как взаимодействовать с Vault и выполнять основные операции.

Возьмите окончательный код из репозитория vault-consul-docker . Ознакомьтесь также с презентацией .

Источник:  https://testdriven.io

#vault #consul 

Hashicorp Vault for secret management in Kubernetes Cluster

INTRODUCTION

Hashicorp Vault provides all of the power and security of Vault, without the complexity and overhead of managing it yourself. It also provides various authentication methods like AWS, Kubernetes, Tokens, OIDC, Azure Active Directory, etc. to provision and dynamically injects secrets in infrastructure like EC2 Machine, Kubernetes pods, etc.

HashiCorp Cloud Platform features a web user interface to deploy and manage resources, including HCP Vault deployments in AWS. However, If you prefer to automate HCP Vault deployment, one recommended approach is to use HashiCorp Terraform with the HCP provider.

What we will cover:

In this post we will cover the following:

  1. Vault installation with High availability configuration in Kubernetes cluster using terraform.
  2. Enabling Kubernetes authentication in Vault using terraform.
  3. Inject Secrets in running pod dynamically.

Pre-requisites

  1. Kubernetes cluster up and running
  2. kubectl, terraform, helm, vault CLI installed
  3. some basic knowledge of terraform, kubectl and vault commands. (I will provide a link in end for reference)

#hashicorp-consul #terraform #hashicorp-vault #automation #kubernetes

Michel  Kub

Michel Kub

1595115540

Webinar: Securing Service Mesh with Kubernetes, Consul and Vault

In this session, we’ll look at using HashiCorp tools to help you as your infrastructure continues to grow, helping to manage secrets, and secure communication between applications running in multiple clusters.

We will demonstrate how to quickly get started with HashiCorp Vault and Consul using the Helm charts. Then, walk through an example application architecture where we secure service to service communication with Consul and securely manage application secrets using Vault.

#kubernetes #consul #vault #securing service mesh #hashicorp tools

How to Set Up and Use Hashicorp's Vault and Consul Projects

The following tutorial details how to set up and use Hashicorp's Vault and Consul projects to securely store and manage secrets.

Source: https://testdriven.io

#vault #consul 

Securing your secrets using vault in Kubernetes — Part 2

In Part 1 of this series, we have learned how to Install Vault-k8s and enable the Kubernetes Auth Mechanism. In this tutorial let’s learn how automatically inject these secrets into our Kubernetes Deployments/Pods.

I have used Helm to create the manifests files. Helm charts are easier to create, version, share, and publish. Copying-and-Pasting the same manifests across multiple environments can be avoided and the same charts can be re-used by maintaining a different final overrides file.

#hashicorp-vault #kubernetes #vault-k8s #vault #kubernetes-secret