Secrets Management v praxi — HashiCorp Vault, SOPS a bezpečná správa tajemství

Každá moderní aplikace pracuje s tajemstvími — databázové přihlašovací údaje, API klíče, TLS certifikáty, šifrovací klíče, tokeny třetích stran. A přesto se stále setkáváme s firmami, které mají hesla natvrdo v kódu, .env soubory commitované do Gitu nebo sdílené přes Slack. V roce 2026 je tohle nejrychlejší cesta k bezpečnostnímu incidentu.

Secrets management není jen o tom „kam dát heslo”. Je to komplexní disciplína zahrnující bezpečné ukládání, distribuci, rotaci, audit a revokaci tajemství v celém životním cyklu aplikace. V tomto článku si projdeme, proč je to důležité, jaké nástroje použít a jak to celé implementovat v praxi.

Proč je secrets management kritický¶

Únik tajemství = otevřené dveře¶

Podle studie GitGuardian se v roce 2025 objevilo přes 12 milionů nových tajemství v public repozitářích na GitHubu. API klíče AWS, databázová hesla, privátní klíče — vše volně přístupné komukoli. A to jsou jen veřejné repozitáře. V privátních je situace často stejná.

Důsledky úniku tajemství: - Finanční ztráty — útočníci s AWS klíčem mohou za hodiny naminovat desítky tisíc dolarů na kryptoměnách - Data breach — databázové credentials vedou přímo k zákaznickým datům - Compliance porušení — GDPR, NIS2, DORA vyžadují ochranu přístupových údajů - Reputační škoda — veřejný únik tajemství signalizuje zralost bezpečnostní kultury

Kde firmy chybují¶

Typické anti-patterny, které vidíme u klientů:

1. Hardcoded secrets v kódu — DB_PASSWORD = "admin123" přímo ve zdrojáku
2. .env soubory v Gitu — i v privátním repu je to riziko (insider threat, compromised account)
3. Sdílená hesla přes chat — Slack, Teams, email — vše je logovatelné a prohledatelné
4. Jedno heslo pro vše — stejné credentials pro dev, staging i produkci
5. Žádná rotace — hesla nastavená před 3 lety, nikdy nezměněná
6. Žádný audit — nikdo neví, kdo a kdy tajemství použil

Architektura secrets managementu¶

Než se pustíme do nástrojů, pojďme si definovat, co kvalitní secrets management systém musí umět:

Základní principy¶

Centralizované úložiště — tajemství žijí na jednom místě, ne rozházená po konfiguracích, CI/CD proměnných a poznámkách v Confluence.

Encryption at rest i in transit — tajemství jsou šifrovaná vždy, nejen při přenosu.

Přístup na principu least privilege — každá služba, uživatel nebo pipeline má přístup pouze k tajemstvím, která skutečně potřebuje.

Automatická rotace — klíče a hesla se pravidelně mění bez manuálního zásahu.

Audit trail — každý přístup k tajemství je logovaný — kdo, kdy, odkud.

Revokace — možnost okamžitě zneplatnit kompromitované tajemství.

Dynamic secrets — místo statických hesel generovat dočasné přihlašovací údaje s omezenou platností.

Vrstvy secrets managementu¶

┌─────────────────────────────────────────┐
│          Aplikace / Služby              │
├─────────────────────────────────────────┤
│    Secret Injection Layer               │
│    (sidecar, init container, SDK)       │
├─────────────────────────────────────────┤
│    Secret Store Interface               │
│    (CSI driver, External Secrets, API)  │
├─────────────────────────────────────────┤
│    Secret Backend                       │
│    (Vault, AWS SM, Azure KV, GCP SM)    │
├─────────────────────────────────────────┤
│    Encryption & Key Management          │
│    (auto-unseal, KMS, HSM)             │
└─────────────────────────────────────────┘

HashiCorp Vault — de facto standard¶

HashiCorp Vault je nejrozšířenější open-source řešení pro secrets management. A má k tomu dobré důvody.

Co Vault umí¶

Secret Engines — pluginové backendy pro různé typy tajemství: - kv (key-value) — klasické ukládání tajemství - database — dynamická generace databázových credentials - pki — vlastní Certificate Authority pro TLS certifikáty - aws / azure / gcp — dynamické cloud credentials - transit — encryption as a service (šifrování bez odhalení klíče) - ssh — signed SSH certifikáty místo statických klíčů

Auth Methods — jak se aplikace a uživatelé autentizují vůči Vaultu: - Kubernetes Service Account - OIDC / JWT - AppRole (pro CI/CD) - Cloud IAM (AWS, Azure, GCP) - LDAP / Active Directory - TLS certifikáty

Policies — granulární řízení přístupu:

# Politika pro platební službu
path "secret/data/payments/*" {
  capabilities = ["read"]
}

path "database/creds/payments-readonly" {
  capabilities = ["read"]
}

# Zakázat přístup k admin tajemstvím
path "secret/data/admin/*" {
  capabilities = ["deny"]
}

Vault v Kubernetes — praktická implementace¶

V Kubernetes prostředí je Vault typicky nasazený jako StatefulSet s Raft storage backend (integrovaný consensus):

# Vault Helm values
server:
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true
      setNodeId: true

  resources:
    requests:
      memory: 256Mi
      cpu: 250m
    limits:
      memory: 512Mi
      cpu: 500m

  auditStorage:
    enabled: true
    size: 10Gi

  # Auto-unseal přes Azure Key Vault
  seal:
    azurekeyvault:
      tenant_id: "xxx"
      vault_name: "core-vault-unseal"
      key_name: "vault-auto-unseal"

injector:
  enabled: true
  resources:
    requests:
      memory: 64Mi
      cpu: 50m

Vault Agent Injector¶

Nejelegantnější způsob, jak dostat tajemství do podů v Kubernetes, je Vault Agent Injector. Funguje jako mutating webhook — automaticky přidá init container a sidecar, které stáhnou tajemství do souboru v podu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "payment-service"
        vault.hashicorp.com/agent-inject-secret-db: "database/creds/payments-rw"
        vault.hashicorp.com/agent-inject-template-db: |
          {{- with secret "database/creds/payments-rw" -}}
          postgresql://{{ .Data.username }}:{{ .Data.password }}@db.core.internal:5432/payments
          {{- end }}
    spec:
      serviceAccountName: payment-service
      containers:
        - name: app
          image: core/payment-service:latest
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: vault-db
                  key: connection_string

Krása tohoto přístupu: aplikace neví o Vaultu. Čte tajemství ze souboru nebo environment proměnné — Vault Agent se postará o autentizaci, stažení a automatický refresh při rotaci.

Dynamic Secrets — game changer¶

Statická hesla jsou jako klíče od bytu: jakmile je někdo okopíruje, má přístup navždy. Dynamic secrets tento problém eliminují.

Vault umí generovat databázové credentials on-the-fly s omezenou platností:

# Konfigurace database secret engine
vault write database/config/payments \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db:5432/payments" \
  allowed_roles="payments-rw,payments-ro" \
  username="vault-admin" \
  password="super-secret-admin-password"

# Definice role s TTL 1 hodina
vault write database/roles/payments-rw \
  db_name=payments \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT ALL ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  revocation_statements="REVOKE ALL ON ALL TABLES IN SCHEMA public FROM \"{{name}}\"; DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

Každý request na database/creds/payments-rw vygeneruje unikátní uživatelské jméno a heslo s platností 1 hodina. Po expiraci Vault credentials automaticky revokuje. Pokud dojde k úniku, credentials jsou platné maximálně hodinu — dramatické snížení blast radius.

Mozilla SOPS — šifrování pro GitOps¶

Ne každá organizace potřebuje (nebo chce) provozovat plnohodnotný Vault cluster. Pro menší týmy nebo jako doplněk k Vaultu existuje Mozilla SOPS (Secrets OPerationS).

Jak SOPS funguje¶

SOPS šifruje hodnoty v YAML, JSON nebo ENV souborech, zatímco klíče (keys) nechává čitelné. To umožňuje commitovat šifrované tajemství přímo do Gitu a přitom vidět strukturu konfigurace:

# Před šifrováním
database:
  host: db.production.internal
  port: 5432
  username: app_user
  password: SuperSecretPassword123

# Po šifrování SOPS
database:
  host: db.production.internal  # nešifrováno — není tajemství
  port: 5432
  username: ENC[AES256_GCM,data:kBqPdA==,iv:...,tag:...]
  password: ENC[AES256_GCM,data:1xMfNZK3nQ==,iv:...,tag:...]
sops:
  kms:
    - arn: arn:aws:kms:eu-central-1:123456:key/abc-def
  azure_kv:
    - vaultUrl: https://core-sops.vault.azure.net
      key: sops-key
      version: abc123
  lastmodified: "2026-02-16T10:30:00Z"
  mac: ENC[AES256_GCM,data:...,tag:...]

SOPS v praxi¶

# Inicializace s Azure Key Vault
export SOPS_AZURE_KEYVAULT_URLS="https://core-sops.vault.azure.net/keys/sops-key/abc123"

# Šifrování souboru
sops --encrypt --azure-kv https://core-sops.vault.azure.net/keys/sops-key/abc123 \
  secrets.yaml > secrets.enc.yaml

# Editace (dešifruje, otevře editor, znovu zašifruje)
sops secrets.enc.yaml

# Dešifrování pro deployment
sops --decrypt secrets.enc.yaml | kubectl apply -f -

SOPS + Flux/ArgoCD¶

Pro GitOps workflow je SOPS ideální. Argo CD i Flux mají nativní podporu:

# Flux Kustomization s SOPS dešifrováním
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: production-secrets
spec:
  interval: 10m
  path: ./clusters/production/secrets
  prune: true
  sourceRef:
    kind: GitRepository
    name: infrastructure
  decryption:
    provider: sops
    secretRef:
      name: sops-azure-credentials

External Secrets Operator — most mezi světy¶

External Secrets Operator (ESO) řeší častý problém: aplikace v Kubernetes očekávají klasické Secret objekty, ale tajemství žijí ve Vaultu, AWS Secrets Manager nebo Azure Key Vault. ESO vytváří a synchronizuje Kubernetes Secrets z externích zdrojů.

# Definice externího zdroje (ClusterSecretStore)
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: azure-keyvault
spec:
  provider:
    azurekv:
      tenantId: "xxx"
      vaultUrl: "https://core-production.vault.azure.net"
      authSecretRef:
        clientId:
          name: azure-credentials
          namespace: external-secrets
          key: client-id
        clientSecret:
          name: azure-credentials
          namespace: external-secrets
          key: client-secret

---
# Synchronizace tajemství
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payment-db-credentials
  namespace: payments
spec:
  refreshInterval: 5m
  secretStoreRef:
    kind: ClusterSecretStore
    name: azure-keyvault
  target:
    name: payment-db-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: payments-db-username
    - secretKey: password
      remoteRef:
        key: payments-db-password

ESO pravidelně kontroluje externí zdroj a aktualizuje Kubernetes Secret. Pokud se heslo v Azure Key Vault změní, ESO ho do 5 minut propaguje do clusteru.

Secrets v CI/CD pipeline¶

CI/CD pipeline je kritický bod — potřebuje přístup k tajemstvím pro deployment, ale zároveň je to vysokorizikové prostředí (sdílené runnery, logy, artefakty).

Zásady pro CI/CD¶

1. Nikdy nelogovat tajemství — maskování v logech nestačí, lepší je tajemství vůbec nevystavovat jako proměnné
2. Krátkodobé tokeny — Vault AppRole s TTL 15 minut pro pipeline
3. Izolace per-environment — staging pipeline nemá přístup k produkčním tajemstvím
4. OIDC federace — GitHub Actions a GitLab CI podporují OIDC tokeny, které lze vyměnit za Vault/cloud credentials bez statických secrets

# GitHub Actions — OIDC autentizace vůči Vaultu
jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Import secrets from Vault
        uses: hashicorp/vault-action@v3
        with:
          url: https://vault.core.internal
          method: jwt
          role: github-deploy
          jwtGithubAudience: https://vault.core.internal
          secrets: |
            secret/data/production/db password | DB_PASSWORD ;
            secret/data/production/api key | API_KEY

      - name: Deploy
        run: |
          helm upgrade --install app ./chart \
            --set db.password=${{ steps.vault.outputs.DB_PASSWORD }}

Pre-commit hooks proti úniku¶

Prevence je lepší než detekce. Nástroje jako gitleaks, trufflehog nebo detect-secrets skenují commity před pushnutím:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Nebo standalone
gitleaks detect --source . --verbose

V CI/CD pipeline pak běží jako gate:

# GitLab CI
secret-scan:
  stage: security
  image: ghcr.io/gitleaks/gitleaks:latest
  script:
    - gitleaks detect --source . --report-format sarif --report-path gitleaks.sarif
  artifacts:
    reports:
      sast: gitleaks.sarif

Rotace tajemství — automatizace je klíč¶

Manuální rotace hesel je odsouzená k selhání. Buď se neprovádí vůbec, nebo způsobí výpadky kvůli neaktualizovaným konfiguracím.

Strategie rotace¶

Vault dynamic secrets — nejelegantnější. Tajemství se negenerují dopředu, ale on-demand s omezenou platností. Rotace je implicitní.

Vault rotation policy — pro statická tajemství (API klíče třetích stran), kde Vault pravidelně zavolá rotační endpoint:

# Automatická rotace každých 30 dní
vault write sys/policies/password/rotation \
  policy='length=32 rule "charset" { charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*" }'

Blue-green rotation — pro tajemství, která nelze rotovat atomicky: 1. Vytvořit nové tajemství (green) 2. Aktualizovat všechny konzumenty 3. Ověřit, že staré tajemství (blue) se nepoužívá 4. Revokovat staré tajemství

Monitoring a alerting¶

# Prometheus alert pro expirující tajemství
groups:
  - name: secrets
    rules:
      - alert: SecretExpiringIn7Days
        expr: vault_secret_lease_remaining_seconds < 604800
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "Secret {{ $labels.path }} expires in less than 7 days"

      - alert: SecretRotationFailed
        expr: vault_secret_rotation_failures_total > 0
        for: 5m
        labels:
          severity: critical

Cloud-native alternativy¶

Ne vždy je Vault správná volba. Pokud jste all-in na jednom cloudu, nativní služby mohou být jednodušší:

Azure Key Vault¶

// .NET aplikace s Azure Key Vault
var client = new SecretClient(
    new Uri("https://core-production.vault.azure.net"),
    new DefaultAzureCredential()
);

KeyVaultSecret secret = await client.GetSecretAsync("database-password");
string connectionString = $"Server=db.core.internal;Password={secret.Value}";

Výhody: nativní integrace s Azure AD, managed identity (žádné credentials pro přístup k credentials), automatická rotace přes Event Grid + Azure Functions.

AWS Secrets Manager¶

import boto3

client = boto3.client('secretsmanager', region_name='eu-central-1')
response = client.get_secret_value(SecretId='production/database')
secret = json.loads(response['SecretString'])

AWS nabízí built-in rotaci pro RDS, Redshift a DocumentDB — stačí zapnout a nastavit interval.

Porovnání¶

Vlastnost	Vault	Azure KV	AWS SM	GCP SM
Multi-cloud	✅	❌	❌	❌
Dynamic secrets	✅	❌	❌	❌
PKI/CA	✅	❌	❌	❌
Encryption as Service	✅	✅	✅	✅
Automatická rotace	✅	✅	✅	✅
Provozní náklady	Vysoké	Nízké	Nízké	Nízké
Vendor lock-in	Ne	Ano	Ano	Ano
Open-source	Ano	Ne	Ne	Ne

Naše doporučení: Vault pro multi-cloud a komplexní prostředí, cloud-native řešení pro single-cloud s jednoduchými potřebami.

Implementační checklist¶

Pokud začínáte se secrets managementem, postupujte podle tohoto plánu:

Fáze 1 — Audit (týden 1–2)¶

• [ ] Inventura všech tajemství (kód, CI/CD, konfigurace, dokumentace)
• [ ] Klasifikace podle citlivosti (critical, high, medium, low)
• [ ] Identifikace vlastníků tajemství
• [ ] Sken repozitářů pomocí gitleaks/trufflehog

Fáze 2 — Centralizace (týden 3–4)¶

• [ ] Nasazení Vaultu / konfigurace cloud-native řešení
• [ ] Migrace critical tajemství jako první
• [ ] Nastavení přístupových politik (least privilege)
• [ ] Zapnutí audit logů

Fáze 3 — Automatizace (týden 5–8)¶

• [ ] CI/CD integrace (OIDC, AppRole)
• [ ] Kubernetes integrace (ESO nebo Vault Injector)
• [ ] Automatická rotace pro databázové credentials
• [ ] Pre-commit hooks proti úniku

Fáze 4 — Monitoring (ongoing)¶

• [ ] Alerting na expirující tajemství
• [ ] Pravidelný audit přístupů
• [ ] Penetrační testování secrets managementu
• [ ] Quarterly review přístupových politik

Závěr¶

Secrets management není sexy téma — dokud se nestanou. Únik API klíče, databázového hesla nebo privátního certifikátu může mít fatální následky. Investice do správného řešení se vrátí mnohonásobně.

Klíčové takeaways: - Centralizujte — jedno místo pro všechna tajemství - Automatizujte rotaci — manuální rotace nefunguje - Používejte dynamic secrets kde to jde — eliminují problém úniku - Skenujte kód — pre-commit hooks zachytí chyby dřív, než se dostanou do Gitu - Auditujte — logujte každý přístup, nastavte alerting

V CORE SYSTEMS implementujeme secrets management jako součást každého projektu. Bezpečnost není add-on — je to fundament. Pokud řešíte správu tajemství ve své organizaci, ozvěte se nám — rádi pomůžeme s architekturou i implementací.

---

Potřebujete pomoct se secrets managementem nebo celkovou bezpečnostní architekturou? Podívejte se na naše security služby nebo nás kontaktujte přímo.