HashiCorp Vault — centralne zarządzanie sekretami

Opublikowano: 9 kwietnia 2026 · Kategoria: Bezpieczeństwo

Trzymanie haseł do bazy w pliku .env dołączanym do kodu, kopiowanym po SSH między serwerami i wklejanym do Slack-a to najczęstszy powód wycieków danych. HashiCorp Vault rozwiązuje ten problem przez centralizację — wszystkie sekrety są w jednym miejscu, z kontrolą dostępu po rolach, audit logiem każdego odczytu i mechanizmami rotacji. Najważniejszą funkcją Vaulta są dynamic secrets: zamiast jednego hasła do bazy żyjącego miesiącami, aplikacja dostaje hasło ważne godzinę, po czym Vault sam usuwa konto. Ten artykuł pokazuje instalację, inicjalizację, podstawowe użycie KV engine, uwierzytelnianie AppRole i integrację z PostgreSQL.

Instalacja i pierwsze uruchomienie

# Ubuntu / Debian - oficjalne repo HashiCorp
wget -O- https://apt.releases.hashicorp.com/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vault -y

# Uzytkownik vault jest tworzony automatycznie
# Konfiguracja w /etc/vault.d/vault.hcl

# Uruchomienie w trybie dev (TYLKO do testow, dane w RAM)
vault server -dev
# Zapisz token root i unseal key z outputu

# Ustaw adres serwera Vault
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='hvs.xxxx...'   # z outputu dev

# Sprawdz status
vault status

Produkcja — init, unseal i storage backend

Serwer dev jest wygodny do nauki, ale nie można go używać w produkcji (dane giną przy restarcie, token root jest w logach). Produkcyjny Vault wymaga storage backendu (Raft, Consul, PostgreSQL) i właściwego procesu inicjalizacji. Domyślnie rekomendowany backend to zintegrowany Raft.

# /etc/vault.d/vault.hcl - produkcyjna konfiguracja

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault.d/tls/vault.crt"
  tls_key_file  = "/etc/vault.d/tls/vault.key"
}

api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://vault-1.example.com:8201"
cluster_name = "vault-prod"
ui           = true

# Uruchomienie
sudo systemctl enable --now vault
sudo systemctl status vault

# Inicjalizacja - ZAPISZ output (klucze unseal + token root)
vault operator init -key-shares=5 -key-threshold=3

# Unseal - wprowadz 3 z 5 kluczy
vault operator unseal <klucz-1>
vault operator unseal <klucz-2>
vault operator unseal <klucz-3>

# Zaloguj sie tokenem root (na razie)
vault login <token-root>
vault status

KV engine — statyczne sekrety i polityki dostępu

KV (Key-Value) to najprostszy secret engine — trzyma pary klucz-wartość z wersjonowaniem (KV v2). Każda ścieżka w drzewie Vaulta może mieć przypisaną politykę, która ogranicza kto i jak może czytać/zapisywać sekrety. Poniżej przykład dla typowej aplikacji webowej.

# Wlacz KV engine v2 w sciezce "secret/"
vault secrets enable -version=2 -path=secret kv

# Zapisz sekret
vault kv put secret/myapp/prod/db \
  username=appuser \
  password=supersecret123

# Odczytaj sekret
vault kv get secret/myapp/prod/db
vault kv get -format=json secret/myapp/prod/db

# Historia wersji
vault kv metadata get secret/myapp/prod/db
vault kv get -version=2 secret/myapp/prod/db

# Polityka - plik myapp-readonly.hcl
path "secret/data/myapp/prod/*" {
  capabilities = ["read"]
}
path "secret/metadata/myapp/prod/*" {
  capabilities = ["list"]
}

# Zaladuj polityke
vault policy write myapp-readonly myapp-readonly.hcl
vault policy list
vault policy read myapp-readonly

Dynamic secrets — PostgreSQL i rotacja

Dynamic secrets to flagowa funkcja Vaulta. Aplikacja prosi o dostęp do bazy, Vault tworzy tymczasowego użytkownika PostgreSQL z podanym TTL, zwraca credentials, a po TTL użytkownik jest automatycznie usuwany. Żadnych długo-żyjących haseł. Przykład dla PostgreSQL:

# Wlacz database engine
vault secrets enable database

# Skonfiguruj polaczenie do Postgresa (Vault musi miec konto admin)
vault write database/config/mydb \
  plugin_name=postgresql-database-plugin \
  allowed_roles="readonly" \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=require" \
  username="vault_admin" \
  password="admin_pass"

# Utworz role "readonly" - szablon SQL do stworzenia usera
vault write database/roles/readonly \
  db_name=mydb \
  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"

# Poproś o dynamic credentials
vault read database/creds/readonly
# Key                Value
# ---                -----
# lease_id           database/creds/readonly/abc123
# lease_duration     1h
# username           v-token-readonly-xyz-123
# password           A1b2C3d4E5f6...

# Odnowienie lease (przedluz TTL)
vault lease renew database/creds/readonly/abc123

# Recznie uniewaznij (usun konto)
vault lease revoke database/creds/readonly/abc123

AppRole — uwierzytelnianie aplikacji

Aplikacje nie mogą logować się tokenem root. AppRole to metoda auth zaprojektowana specjalnie pod maszyny: każda aplikacja dostaje role_id (identyfikator, może być w configu) i secret_id (hasło, dostarczane przez orkiestrator — np. przy starcie). Razem generują token sesji. Tabela poniżej porównuje AppRole z innymi metodami auth dostępnymi w Vault.

Audit logs i monitorowanie

Vault nie startuje bez audit device. Każde żądanie i odpowiedź są logowane (z zahashowanymi wartościami sekretów), co daje pełen audit trail. Logi można wysyłać do pliku, syslogu albo do socket-a. Dobre praktyki eksploatacyjne Vaulta:

• Włącz audit log od pierwszego dnia — vault audit enable file file_path=/var/log/vault/audit.log. Bez tego nie zobaczysz kto pobrał jaki sekret.
• Nie używaj tokenu root w codziennej pracy — stwórz użytkowników LDAP lub OIDC z politykami, a token root zapisz i zamknij w sejfie.
• Backup raft storage — vault operator raft snapshot save codziennie, z retencją 30 dni.
• HA cluster (3-5 nodów) — single-node Vault w produkcji to katastrofa. Użyj Raft z 3 lub 5 węzłami.
• Auto-unseal — dla środowisk z częstymi restartami skonfiguruj auto-unseal przez AWS KMS, GCP KMS, Azure Key Vault lub HSM.
• Rotacja leases i secretów — Vault robi to sam, ale monitoruj czy aplikacje poprawnie renewują leases przed wygaśnięciem.

Najczęstsze pytania