Vault Basic Setup
Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
Установка и базовая настройка Hashicorm Vault
Consul
- Consul выступает в качестве бекенда
- Базовая установка Consul https://noname.com.ua/mediawiki/index.php/Consul_Basic_Setup
Базовая настойка Vault
Устновка
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main" sudo apt-get update && sudo apt-get install vault
Подготовка Consul
Есть разные способы - тут привожу пример с использованием терраформ
- Требуется токен (получение токена - https://noname.com.ua/mediawiki/index.php/Consul_Basic_Setup#management_token )
- токен приведен для примера
export CONSUL_TOKEN="4f6037ed-5f62-5463-d165-cbb984791ef1"
- Установить терраформ (если не установлен)
apt install terraform
- Файл с описанием ACL cat acl.tf
variable "consul_datacenter" {
type = string
default = "kilda-fred"
}
provider "consul" {
address = "http://127.0.0.1:8500"
datacenter = var.consul_datacenter
}
resource "consul_acl_policy" "vault_policy" {
name = "vault_policy"
datacenters = [var.consul_datacenter]
rules = <<-RULE
{
"key_prefix": {
"kilda-fred-vault/": {
"policy": "write"
}
},
"node_prefix": {
"": {
"policy": "write"
}
},
"service": {
"vault": {
"policy": "write"
}
},
"agent_prefix": {
"": {
"policy": "write"
}
},
"session_prefix": {
"": {
"policy": "write"
}
}
}
RULE
}
resource "consul_acl_role" "vault_role" {
name = "vault_role"
description = "Role assignet to the Hasicorp Vault service"
policies = [
consul_acl_policy.vault_policy.id
]
service_identities {
service_name = "vault"
}
}
resource "consul_acl_token" "vault_token" {
description = "Token for Vault Server"
roles = [
consul_acl_role.vault_role.name
]
local = true
}
data "consul_acl_token_secret_id" "vault_token" {
accessor_id = consul_acl_token.vault_token.accessor_id
}
output "consul_acl_token_secret_id" {
value = data.consul_acl_token_secret_id.vault_token.secret_id
sensitive = true
}
output "consul_token_for_vault_server_accessor_id" {
value = consul_acl_token.vault_token.accessor_id
sensitive = true
}
- Инициализировать терраформ и применить ACL
terraform init
terraform apply -auto-approve
- Вывод (все токены для примера)
Changes to Outputs: + consul_acl_token_secret_id = (sensitive value) + consul_token_for_vault_server_accessor_id = (sensitive value) consul_acl_policy.vault_policy: Creating... consul_acl_policy.vault_policy: Creation complete after 0s [id=6746941f-5928-65e9-76f1-9653b294ccac] consul_acl_role.vault_role: Creating... consul_acl_role.vault_role: Creation complete after 0s [id=5e56be99-8a8a-865e-50cc-dfa512051d03] consul_acl_token.vault_token: Creating... consul_acl_token.vault_token: Creation complete after 0s [id=5a4ae5cd-8391-f735-e067-4404d859448b] data.consul_acl_token_secret_id.vault_token: Reading... data.consul_acl_token_secret_id.vault_token: Read complete after 0s [id=5a4ae5cd-8391-f735-e067-4404d859448b] Apply complete! Resources: 3 added, 0 changed, 0 destroyed. Outputs:
Посмотреть спрятанные "секретные" значения можно terraform output -json, для дальнейшей работы нужен токен 8ea89f62-e928-06e8-379b-9b1eebb92a67
{
"consul_acl_token_secret_id": {
"sensitive": true,
"type": "string",
"value": "8ea89f62-e928-06e8-379b-9b1eebb92a67"
},
"consul_token_for_vault_server_accessor_id": {
"sensitive": true,
"type": "string",
"value": "5a4ae5cd-8391-f735-e067-4404d859448b"
}
}
Конфигурация Vault
- /etc/vault.d/vault.hcl
- Токен 5a4ae5cd-8391-f735-e067-4404d859448b получен на предыдущем шаге
- Префикс kilda-fred-vault/ должен совпадать в ACL и конфиге
storage "consul" {
address = "127.0.0.1:8500"
path = "kilda-fred-vault/"
token = "8ea89f62-e928-06e8-379b-9b1eebb92a67"
# Register the service at Consul
service = "vault"
service_tags = "home"
}
telemetry {
statsite_address = "127.0.0.1:8125"
disable_hostname = true
}
disable_mlock = true
ui = true
#mlock = true
#disable_mlock = true
#}
# HTTPS listener
listener "tcp" {
address = "0.0.0.0:8200"
tls_cert_file = "/opt/vault/tls/tls.crt"
tls_key_file = "/opt/vault/tls/tls.key"
}
TLS/SSL
- Не забыть установить правильные сертификаты и добавить CA как доверенный
Инициализация
- vault.domain.tld (домен взят для примера) должен соответствовать записям в сертификатах!
export VAULT_ADDR=https://vault.domain.tld:8200
vault operator init
Unseal Key 1: bQjA3QKTHYc9X897PrRPN+wAFqVAYnmGyl2bMioKSYL8 Unseal Key 2: J5K1GVOmWRzP1En1O3h0cZ4Ra80jRDKB3GXmW4HqvJKi Unseal Key 3: exQSVpnNSgVJehnfoYiQGZGyO0tVl3ieriJhsHHfZxci Unseal Key 4: P0f2kd8YLg1mAQyhQNC/kIBcRmZFLER+989kQp0Y8jpP Unseal Key 5: if5E98mspfrQyeCtkmHxJcGVDLrcgWQZpdVUALpn9xKP Initial Root Token: s.pRFenxR9CANXqLtGI0b6fvy3
Ключи приведены для примера
Unseal / разблокирование
три раза запустить vault operator unseal (с разными ключами, любые три из пяти!)
vault operator unseal Unseal Key (will be hidden): Key Value --- ----- Seal Type shamir Initialized true Sealed true ...
vault operator unseal Unseal Key (will be hidden): Key Value --- ----- Seal Type shamir Initialized true Sealed true ...
vault operator unseal Key Value --- ----- Seal Type shamir Initialized true Sealed false ...
Авторизация
Логин/Пароль
Удобно для тестов (другие применения под сомнением)
С рутовым токеном - включить авторизацию по паролю
vault auth enable userpass Success! Enabled userpass auth method at: userpass/
Создать пользователя (в примере - рут с полными правами)
- auth/userpass/users/root - имя пользователя
vault write auth/userpass/users/root \
password=root \
policies=default
Проверка
vault login -method=userpass username=root password=root 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.
K/V Secrets
- Включить K/V
vault secrets enable -version=2 kv
Тут важно помнить что kv это это путь по умолчанию (и по которому потом нужно будет обращаться к данным)
- Задать путь монтирования можно:
vault secrets enable -path=secret/ kv
- Просмотреть пути (в том числе и kv)
vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_5da501f2 per-token private secret storage identity/ identity identity_ba162c0c identity store kv/ kv kv_fbc9f78c n/a sys/ system system_a62acf53 system endpoints used for control, policy and debugging
- Проверить запись и чтение с рутовым токеном
vault kv put kv/test a=b Key Value --- ----- created_time 2022-02-07T15:46:37.731094732Z custom_metadata <nil> deletion_time n/a destroyed false version 1
vault kv get kv/test ======= Metadata ======= Key Value --- ----- created_time 2022-02-07T15:46:37.731094732Z custom_metadata <nil> deletion_time n/a destroyed false version 1 == Data == Key Value --- ----- a b
- Создать ветки для для дальнейшего тестирования
vault kv put kv/kilda cert1=certdata1 Key Value --- ----- created_time 2022-02-07T15:50:05.911522071Z custom_metadata <nil> deletion_time n/a destroyed false
Политики для KV
ВНИМАНИЕ Политики для KV version2 изменились! Появилось ключевое слово описывающее доступ К ЧЕМУ дается
Насколько я понимаю ключевые слова нужно указывать ОДИ раз (т е не писать secret/path1/data/path2/data
- Было так
path "secret/dev/team-1/*" {
capabilities = ["create", "update", "read"]
}
Теперь нужно так:
path "secret/data/dev/team-1/*" {
capabilities = ["create", "update", "read"]
}
Кроме data' доступны следующие значения
To allow the policy to delete any version of a key:
path "secret/delete/dev/team-1/*" {
capabilities = ["update"]
}
To allow a policy to undelete data:
path "secret/undelete/dev/team-1/*" {
capabilities = ["update"]
}
To allow a policy to destroy versions:
path "secret/destroy/dev/team-1/*" {
capabilities = ["update"]
}
To allow a policy to list keys:
path "secret/metadata/dev/team-1/*" {
capabilities = ["list"]
}
To allow a policy to view metadata for each version:
path "secret/metadata/dev/team-1/*" {
capabilities = ["read"]
}
To allow a policy to permanently remove all versions and metadata for a key:
path "secret/metadata/dev/team-1/*" {
capabilities = ["delete"]
}
По сути политики определяют права доступа ТОКЕНА к определнному пути.
Токен же выдается при логине - т е в простейшем случае политики должны назначаться на пользователя (авторизация по логину/паролю)
- Политики удобнее создавать через файл
path "kv/data/kilda/*" {
capabilities = ["read", "list", "create", "update"]
}
path "kv/data/kilda/readonly/*" {
capabilities = ["read"]
}
path "kv/data/kilda/readonly" {
capabilities = ["read"]
}
path "kv/data/kilda/read_and_update/*" {
capabilities = ["read", "update"]
}
path "kv/data/kilda/read_and_update" {
capabilities = ["read", "update"]
}
path "kv/data/kilda/noaccess" {
capabilities = ["deny"]
}
Создание политики из файла:
vault policy write kilda-policy policy-file.hlc Success! Uploaded policy: kilda-policy
Создание пользователя и прикрипление к нему политики
vault write auth/userpass/users/kilda \
password=kilda \
policies=kilda-policy
Проверка работы политики
- Логин по паролю (можно сразу увидеть политику)
vault login -method=userpass username=kilda password=kilda Key Value --- ----- token s.86nfvQMp5onZWfMX7vBrCuTQ token_accessor upt9dXhnzl4NfSFq1Y8PHmPr token_duration 768h token_renewable true token_policies ["default" "kilda-policy"] identity_policies [] policies ["default" "kilda-policy"] token_meta_username kilda
- Запись в ключ kv/kilda запрещена
vault kv put kv/kilda somekey=somedata Error writing data to kv/data/kilda: Error making API request. * permission denied
- В под-путь писать можно
vault kv put kv/kilda/subpath somekey=somedata Key Value --- ----- created_time 2022-02-08T14:59:04.275447933Z custom_metadata <nil> deletion_time n/a destroyed false version 1
- Читать записанное тоже можно
vault kv get kv/kilda/subpath ======= Metadata ======= Key Value --- ----- created_time 2022-02-08T14:59:04.275447933Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ===== Data ===== Key Value --- ----- somekey somedata
- Писать в путь который можно читать или обновлять нельзя (его еще нет)
vault kv put kv/kilda/read_and_update somekey=somedata * permission denied
- Используя рутовый токен можно записать туда данне
vault kv put kv/kilda/read_and_update somekey=somedata_written_by_root Key Value --- ----- created_time 2022-02-08T15:00:44.314831557Z custom_metadata <nil> deletion_time n/a destroyed false version 1
- И после этого пользователь может их прочитать
vault kv get kv/kilda/read_and_update ======= Metadata ======= Key Value --- ----- created_time 2022-02-08T15:00:44.314831557Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ===== Data ===== Key Value --- ----- somekey somedata_written_by_root
- А так же может их перезаписать
vault kv put kv/kilda/read_and_update somekey=somedata_updated_by_user Key Value --- ----- created_time 2022-02-08T15:01:51.414726299Z custom_metadata <nil> deletion_time n/a destroyed false version 2
- Запрещенный путь нельзя ни читать ни писать
vault kv put kv/kilda/noaccess somekey=somedata_updated_by_user * permission denied
vault kv get kv/kilda/noaccess * permission denied
