Autor: [Adam Nadolny](/autorzy/adam-nadolny) Ekspert DevOps i infrastruktury · Zweryfikowano Kwiecień 2026 1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. HashiCorp Vault — sekrety # 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 vault operator unseal vault operator unseal # Zaloguj sie tokenem root (na razie) vault login 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. Metoda auth Dla kogo Siła Typowy use-case Token Ludzie i skrypty Średnia Admin CLI, bootstrap, dev AppRole Aplikacje Wysoka (z response wrapping) Backend aplikacji, daemony Kubernetes Pody K8s Bardzo wysoka Mikrousługi w klastrach K8s AWS IAM EC2, Lambda, ECS Bardzo wysoka Workloady w AWS, integracja IAM LDAP / OIDC Ludzie Wysoka (z MFA) UI Vault dla zespołu, SSO GitHub / GitLab CI/CD pipelines Średnia Deploy z GitHub Actions, GitLab CI TLS Certificate Maszyny z PKI Bardzo wysoka Usługi mTLS w service mesh ## 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 Do czego służy HashiCorp Vault? + HashiCorp Vault to narzędzie do centralnego zarządzania sekretami: hasła, tokeny API, klucze SSH, certyfikaty TLS, klucze szyfrowania. Zamiast trzymać sekrety w .env, kodzie lub plikach konfiguracyjnych, aplikacje pobierają je z Vaulta na żądanie. Vault obsługuje także dynamic secrets — krótko-żyjące dane dostępowe generowane ad-hoc dla baz danych, cloudów i innych systemów. Czym jest unseal w Vault i jak działa? + Po uruchomieniu Vault jest w stanie sealed — nie umie odszyfrować swoich danych i nie odpowiada na żądania. Unseal to proces wprowadzenia N z M kluczy unseal (Shamir Secret Sharing, domyślnie 3 z 5). Klucze unseal są generowane podczas vault operator init i muszą być przechowywane OSOBNO przez różne osoby. Każdy restart serwera wymaga unseal — chyba że używasz auto-unseal (KMS, Transit, HSM). Co to są dynamic secrets w Vault? + Dynamic secrets to krótko-żyjące dane dostępowe generowane przez Vault na żądanie. Przykład: aplikacja prosi o dostęp do MySQL, Vault tworzy tymczasowe konto db z TTL 1h, zwraca username+password, a po TTL konto jest automatycznie usuwane. Eliminuje to długo-żyjące credentials, które można wykraść. Vault ma dynamic secrets engines dla baz (MySQL, PostgreSQL, MSSQL), clouds (AWS, GCP, Azure), SSH, PKI i wielu innych. Czym Vault różni się od AWS Secrets Manager? + AWS Secrets Manager to managed service AWS, działa tylko w AWS i dla zasobów AWS. Vault jest self-hosted (lub HCP Vault Cloud), działa wszędzie (on-premise, multi-cloud, hybrid) i ma znacznie bogatszy zestaw funkcji: dynamic secrets dla nie-AWS baz, PKI, transit encryption, SSH CA, szczegółowy ACL przez policies. Vault jest bardziej elastyczny, ale wymaga samodzielnej obsługi (backups, HA, upgrades). Secrets Manager jest prostszy, ale lock-in do AWS. ## Sprawdź oferty pasujące do tego scenariusza Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne. Contabo VPS pod Vault cluster — dużo RAM i NVMe dla storage VPS + NVMe [Aktywuj rabat →](/out/contabo) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) ProSerwer.pl Polski VPS pod self-hosted Vault dla zgodności z RODO Polski VPS [Aktywuj rabat →](/out/proserwer-pl) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/proserwer) Mikr.us Budżetowy VPS do testów Vault w trybie dev Dev/Test [Aktywuj rabat →](/out/mikrus) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) ## Powiązane strony - [Bezpieczeństwo VPS — checklist](/baza-wiedzy/bezpieczenstwo-vps-checklist) - [auditd — audyt bezpieczeństwa Linux](/baza-wiedzy/auditd-logi-audytu-linux) - [Ansible — podstawy automatyzacji](/baza-wiedzy/ansible-podstawy-automatyzacja) - [Wszystkie artykuły](/baza-wiedzy/)