Zarządzanie sekretami na Linux w 2026 — SOPS, age, HashiCorp Vault i OpenBao w praktyce

Dlaczego zarządzanie sekretami jest kluczowe dla bezpieczeństwa Linuksa

Ręka do góry — kto nigdy nie wrzucił hasła do bazy wprost do pliku .env i nie puścił tego na repo? No właśnie. Każde środowisko serwerowe oparte na Linuksie operuje dziesiątkami, a nierzadko setkami wrażliwych danych: hasła do baz, klucze API, tokeny uwierzytelniające, certyfikaty TLS, klucze prywatne SSH. Lista ciągnie się i ciągnie.

W 2026 roku sytuacja jest szczególnie napięta. Cykle eksploatacji podatności skróciły się do godzin, ataki na łańcuch dostaw stały się codziennością, a trzymanie sekretów w zmiennych środowiskowych czy (co gorsza) bezpośrednio w kodzie źródłowym to po prostu zaproszenie do katastrofy.

W tym poradniku przejdziemy przez kompletny ekosystem narzędzi do zarządzania sekretami na Linuksie: od lekkiego szyfrowania plików za pomocą SOPS + age, przez scentralizowane rozwiązanie HashiCorp Vault, aż po jego w pełni otwartoźródłowy fork — OpenBao. Każde narzędzie zilustrujemy działającymi przykładami kodu i konfiguracjami, które możesz wdrożyć od razu w swoim pipeline CI/CD.

SOPS + age — szyfrowanie sekretów w repozytorium Git

Czym jest SOPS i dlaczego warto go używać

SOPS (Secrets OPerationS) to narzędzie CNCF do szyfrowania plików konfiguracyjnych w formatach YAML, JSON, ENV, INI i binarnych. To, co wyróżnia SOPS na tle innych narzędzi, jest genialne w swojej prostocie — szyfruje wyłącznie wartości, zostawiając klucze (nazwy pól) w postaci jawnej. Dzięki temu zaszyfrowane pliki pozostają czytelne w diffach Git, co umożliwia normalny code review nawet dla zmian w sekretach.

Najnowsza wersja stabilna to SOPS v3.12.2 (marzec 2026), zbudowana z Go 1.24 i dostępna na licencji MPL-2.0.

Czym jest age i dlaczego zastępuje GPG

age to nowoczesne narzędzie szyfrujące stworzone przez Filippo Valsordę (dawniej zespół bezpieczeństwa Go w Google). Jeśli kiedykolwiek walczyłeś z GPG — z jego rozbudowanym key ringiem, wygasającymi subkluczami i nieintuicyjnym interfejsem — to age jest jak powiew świeżego powietrza. Prostszy model kluczy, mniejsze pliki, lepsza automatyzacja i silniejsza kryptografia (X25519 + ChaCha20-Poly1305).

W 2026 roku age stało się domyślnym backendem szyfrowania dla SOPS w większości nowych wdrożeń. I szczerze? Trudno się dziwić.

Instalacja SOPS i age na Linux

# Instalacja age (v1.2.0)
wget https://github.com/FiloSottile/age/releases/download/v1.2.0/age-v1.2.0-linux-amd64.tar.gz
tar xzf age-v1.2.0-linux-amd64.tar.gz
sudo install -m 755 age/age /usr/local/bin/age
sudo install -m 755 age/age-keygen /usr/local/bin/age-keygen

# Instalacja SOPS (v3.12.2)
wget https://github.com/getsops/sops/releases/download/v3.12.2/sops-v3.12.2.linux.amd64
sudo install -m 755 sops-v3.12.2.linux.amd64 /usr/local/bin/sops

# Weryfikacja
age --version
sops --version

Generowanie kluczy age

# Utwórz katalog na klucze
mkdir -p ~/.config/sops/age

# Wygeneruj parę kluczy
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt

# Wyświetl klucz publiczny
grep "public key" ~/.config/sops/age/keys.txt
# Przykładowy wynik:
# public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

Konfiguracja .sops.yaml w projekcie

Plik .sops.yaml w katalogu głównym repozytorium to serce całej konfiguracji — określa, które pliki szyfrować, jakimi kluczami i jakie pola mają być chronione:

# .sops.yaml
creation_rules:
  # Szyfruj tylko wrażliwe pola w plikach secrets*.yaml
  - path_regex: secrets.*\.yaml$
    encrypted_regex: "^(password|token|secret|key|api_key|private)$"
    age: >-
      age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p,
      age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

  # Szyfruj wszystkie wartości w plikach env
  - path_regex: \.env\.encrypted$
    age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

Szyfrowanie i odszyfrowywanie plików

No dobrze, teraz najciekawsza część — zobaczmy, jak to wygląda w praktyce:

# Przykładowy plik secrets.yaml (przed szyfrowaniem)
cat secrets.yaml
# database_password: SuperTajneHaslo123
# api_key: sk-prod-abcdef123456
# app_name: moja-aplikacja
# debug: false

# Zaszyfruj plik w miejscu
export SOPS_AGE_KEY_FILE=~/.config/sops/age/keys.txt
sops --encrypt --in-place secrets.yaml

# Sprawdź wynik — klucze widoczne, wartości zaszyfrowane
cat secrets.yaml
# database_password: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]
# api_key: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]
# app_name: moja-aplikacja
# debug: false

# Odszyfruj do stdout (bez modyfikacji pliku)
sops --decrypt secrets.yaml

# Edytuj zaszyfrowany plik w edytorze (odszyfruje → edycja → zaszyfruje)
sops secrets.yaml

Zwróć uwagę na coś ważnego — pola app_name i debug nie zostały zaszyfrowane, bo nie pasują do wzorca encrypted_regex. Tylko wartości oznaczone jako wrażliwe trafiają pod szyfrowanie. Eleganckie, prawda?

Integracja SOPS z GitHub Actions

# .github/workflows/deploy.yml
name: Deploy z sekretami SOPS
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Instalacja SOPS i age
        run: |
          wget -qO /usr/local/bin/sops \
            https://github.com/getsops/sops/releases/download/v3.12.2/sops-v3.12.2.linux.amd64
          chmod +x /usr/local/bin/sops
          sudo apt-get install -y age

      - name: Odszyfruj sekrety
        env:
          SOPS_AGE_KEY: ${{ secrets.SOPS_AGE_PRIVATE_KEY }}
        run: |
          sops --decrypt config/secrets.yaml > config/secrets.decrypted.yaml

      - name: Wdrożenie aplikacji
        run: |
          # Użyj odszyfrowanych sekretów w procesie wdrażania
          ./scripts/deploy.sh --config config/secrets.decrypted.yaml

      - name: Wyczyść sekrety
        if: always()
        run: rm -f config/secrets.decrypted.yaml

Ten krok Wyczyść sekrety z if: always() na końcu jest kluczowy. Nawet jeśli wdrożenie się wysypie, odszyfrowane pliki zostaną usunięte. To drobny szczegół, ale właśnie takie drobiazgi robią różnicę między bezpiecznym a dziurawym pipeline.

Rotacja kluczy age w SOPS

# 1. Wygeneruj nowy klucz
age-keygen -o new-key.txt

# 2. Zaktualizuj .sops.yaml — dodaj nowy klucz publiczny, usuń stary

# 3. Zaktualizuj klucze we wszystkich zaszyfrowanych plikach
find . -name "secrets*.yaml" | while read f; do
  if grep -q "sops:" "$f"; then
    sops updatekeys --yes "$f"
  fi
done

# 4. Potwierdź, że nowy klucz działa
sops --decrypt secrets.yaml > /dev/null && echo "Rotacja kluczy zakończona pomyślnie"

HashiCorp Vault — scentralizowane zarządzanie sekretami

Kiedy wybrać Vault zamiast SOPS

SOPS świetnie sprawdza się przy szyfrowaniu plików w Git — jest prosty, lekki i nie wymaga żadnej infrastruktury. Ale prędzej czy później trafisz na ścianę. Brak dynamicznych sekretów, brak automatycznej rotacji, brak granularnej kontroli dostępu, brak logów audytowych.

W środowiskach produkcyjnych z wieloma zespołami i usługami potrzebujesz czegoś więcej. HashiCorp Vault to de facto standard branżowy — oferuje dynamiczne generowanie poświadczeń, polityki dostępu w języku HCL, szyfrowanie jako usługę (Transit Engine) i pełny audit trail.

Jest jednak pewien haczyk. Od 2023 roku Vault działa na licencji BSL 1.1 (Business Source License), co ogranicza jego użycie w usługach komercyjnych konkurujących z HashiCorp. Dla wielu organizacji to istotne ograniczenie — i właśnie dlatego powstał OpenBao (ale o tym za chwilę).

Instalacja Vault w trybie dev na Linux

# Pobranie Vault (wersja 1.18)
wget https://releases.hashicorp.com/vault/1.18.4/vault_1.18.4_linux_amd64.zip
unzip vault_1.18.4_linux_amd64.zip
sudo install -m 755 vault /usr/local/bin/vault

# Uruchomienie serwera dev (wyłącznie do testów — nie używać w produkcji!)
vault server -dev -dev-root-token-id="dev-token-123" &

# Konfiguracja klienta
export VAULT_ADDR="http://127.0.0.1:8200"
export VAULT_TOKEN="dev-token-123"

# Sprawdzenie statusu
vault status

Przechowywanie i pobieranie sekretów

# Włącz silnik KV v2 (Key-Value z wersjonowaniem)
vault secrets enable -path=apps kv-v2

# Zapisz sekret
vault kv put apps/produkcja/baza-danych \
  username="app_user" \
  password="ZlozonEHasl0!2026" \
  host="db.internal.local" \
  port="5432"

# Odczytaj sekret
vault kv get apps/produkcja/baza-danych

# Odczytaj konkretne pole (idealne do skryptów)
vault kv get -field=password apps/produkcja/baza-danych

# Wyświetl historię wersji
vault kv metadata get apps/produkcja/baza-danych

Wersjonowanie w KV v2 to jedna z tych funkcji, które doceniasz dopiero po tym, jak ktoś przypadkiem nadpisze produkcyjne hasło. Zdarza się to częściej niż byśmy chcieli przyznać.

Dynamiczne sekrety — generowanie tymczasowych poświadczeń PostgreSQL

To jest moim zdaniem najciekawsza funkcja Vault. Zamiast przechowywać statyczne hasło do bazy danych, Vault generuje tymczasowe poświadczenia na żądanie — z automatycznym wygaśnięciem:

# Włącz silnik bazy danych
vault secrets enable database

# Skonfiguruj połączenie z PostgreSQL
vault write database/config/produkcja-pg \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-readonly" \
  connection_url="postgresql://{{username}}:{{password}}@db.internal.local:5432/appdb?sslmode=require" \
  username="vault_admin" \
  password="AdminPass2026!"

# Utwórz rolę z krótkoterminowymi poświadczeniami
vault write database/roles/app-readonly \
  db_name=produkcja-pg \
  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"

# Wygeneruj tymczasowe poświadczenia (ważne 1 godzinę)
vault read database/creds/app-readonly
# Key                Value
# ---                -----
# lease_id           database/creds/app-readonly/abcd1234
# lease_duration     1h
# username           v-app-readonly-xyz789
# password           A1b2C3d4-TymczasoweHaslo

Po godzinie te poświadczenia po prostu przestają istnieć. Nawet jeśli wyciekną — okno ataku jest drastycznie ograniczone.

Polityki dostępu w Vault

# Plik polityki: app-team.hcl
cat > app-team.hcl <<'POLICY'
# Dostęp tylko do odczytu sekretów aplikacji
path "apps/data/produkcja/*" {
  capabilities = ["read", "list"]
}

# Generowanie tymczasowych poświadczeń do bazy
path "database/creds/app-readonly" {
  capabilities = ["read"]
}

# Brak dostępu do konfiguracji i administracji
path "sys/*" {
  capabilities = ["deny"]
}
POLICY

# Zastosuj politykę
vault policy write app-team app-team.hcl

# Utwórz token z ograniczoną polityką
vault token create -policy="app-team" -ttl="8h"

OpenBao — w pełni otwartoźródłowa alternatywa dla Vault

Dlaczego OpenBao zyskuje na popularności

Zmiana licencji HashiCorp Vault na BSL 1.1 w 2023 roku wywołała spore zamieszanie w społeczności open source (delikatnie mówiąc). W odpowiedzi powstał OpenBao — fork Vault zarządzany przez Linux Foundation, dostępny na licencji MPL 2.0.

W marcu 2026 roku najnowsza wersja to OpenBao 2.5.2, która wprowadza naprawdę ciekawe usprawnienia: poziome skalowanie odczytów (standby nodes obsługują żądania read-only) oraz deklaratywną dystrybucję wtyczek przez obrazy OCI. Obie te funkcje w Vault dostępne są wyłącznie w wersji Enterprise.

OpenBao zachowuje pełną kompatybilność API z Vault, więc istniejące integracje, polityki HCL i narzędzia klienckie działają bez zmian. Migracja z Vault do OpenBao jest w większości przypadków zaskakująco bezbolesna.

Instalacja i uruchomienie OpenBao

# Pobranie OpenBao v2.5.2
wget https://github.com/openbao/openbao/releases/download/v2.5.2/bao_2.5.2_linux_amd64.zip
unzip bao_2.5.2_linux_amd64.zip
sudo install -m 755 bao /usr/local/bin/bao

# Uruchomienie serwera dev
bao server -dev -dev-root-token-id="dev-bao-token" &

# Konfiguracja klienta
export BAO_ADDR="http://127.0.0.1:8200"
export BAO_TOKEN="dev-bao-token"

# Komendy są identyczne jak w Vault
bao status
bao secrets enable -path=apps kv-v2
bao kv put apps/produkcja/api-service \
  api_key="sk-bao-prod-2026-xyz789" \
  webhook_secret="whsec_bao123456"

# Odczyt
bao kv get -field=api_key apps/produkcja/api-service

Widzisz to? Dosłownie zamieniasz vault na bao w komendach i wszystko działa. Próg wejścia jest minimalny, jeśli znasz już Vault.

Porównanie: Vault vs OpenBao w 2026

Cecha	HashiCorp Vault	OpenBao
Licencja	BSL 1.1	MPL 2.0 (w pełni open source)
Najnowsza wersja (marzec 2026)	1.18.x	2.5.2
Zarządzanie	HashiCorp / IBM	Linux Foundation
Kompatybilność API	—	Pełna z Vault API
Dynamiczne sekrety	Tak	Tak
Horizontal read scaling	Enterprise	Wbudowane (od v2.5)
Dystrybucja wtyczek OCI	Enterprise	Wbudowane (od v2.5)
Wsparcie komercyjne	HashiCorp	Społeczność + kontrybutorzy IBM

Integracja z pipeline CI/CD — kompletny przepływ

Model hybrydowy: SOPS + Vault w jednym pipeline

Oto coś, co sprawdza się w praktyce naprawdę dobrze — model hybrydowy. SOPS do szyfrowania konfiguracji statycznych w repozytorium Git, a Vault/OpenBao do dynamicznego generowania poświadczeń w runtime. Każde narzędzie robi to, w czym jest najlepsze.

Przykładowy pipeline GitLab CI:

# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

variables:
  VAULT_ADDR: "https://vault.internal.company.com:8200"

.vault_auth: &vault_auth
  before_script:
    # Uwierzytelnienie w Vault za pomocą JWT GitLab CI
    - export VAULT_TOKEN=$(vault write -field=token auth/jwt/login \
        role="deploy-role" \
        jwt="${CI_JOB_JWT_V2}")

test:
  stage: test
  script:
    # SOPS do odszyfrowania konfiguracji testowej
    - sops --decrypt config/test-secrets.yaml > /tmp/test-config.yaml
    - pytest --config /tmp/test-config.yaml
  after_script:
    - rm -f /tmp/test-config.yaml

deploy_production:
  stage: deploy
  <<: *vault_auth
  script:
    # Vault do pobrania dynamicznych poświadczeń produkcyjnych
    - DB_CREDS=$(vault read -format=json database/creds/app-deploy)
    - export DB_USER=$(echo $DB_CREDS | jq -r '.data.username')
    - export DB_PASS=$(echo $DB_CREDS | jq -r '.data.password')

    # SOPS do odszyfrowania konfiguracji aplikacji
    - sops --decrypt config/prod-secrets.yaml > /tmp/prod-config.yaml

    # Wdrożenie z tymczasowymi poświadczeniami
    - ansible-playbook deploy.yml \
        -e "db_user=$DB_USER" \
        -e "db_pass=$DB_PASS" \
        -e "@/tmp/prod-config.yaml"
  after_script:
    - rm -f /tmp/prod-config.yaml
    # Poświadczenia Vault wygasają automatycznie po TTL
  only:
    - main

Pre-commit hook — ochrona przed commitem niezaszyfrowanych sekretów

Ten hook uratował mi skórę więcej razy, niż chciałbym przyznać. Instalujesz go raz i masz pewność, że niezaszyfrowany plik z sekretami nigdy nie trafi do repozytorium:

#!/bin/bash
# .git/hooks/pre-commit — blokuje commit niezaszyfrowanych plików secrets
set -euo pipefail

SECRETS_PATTERN="secrets.*\.yaml$|\.env\.encrypted$"

for file in $(git diff --cached --name-only); do
  if echo "$file" | grep -qE "$SECRETS_PATTERN"; then
    if ! grep -q "sops:" "$file" 2>/dev/null; then
      echo "BŁĄD: Plik $file nie jest zaszyfrowany przez SOPS!"
      echo "Uruchom: sops --encrypt --in-place $file"
      exit 1
    fi

    # Sprawdź, czy metadane SOPS zawierają poprawny klucz age
    if ! grep -q "age1" "$file" 2>/dev/null; then
      echo "OSTRZEŻENIE: Plik $file nie zawiera odbiorcy age w metadanych SOPS"
      exit 1
    fi
  fi
done

echo "Pre-commit: Wszystkie pliki sekretów poprawnie zaszyfrowane."

Najlepsze praktyki zarządzania sekretami na Linuksie

Zasada najmniejszych uprawnień

Każda usługa, użytkownik i pipeline powinny mieć dostęp wyłącznie do tych sekretów, które są im faktycznie niezbędne — i ani jednego więcej. W Vault/OpenBao realizujesz to za pomocą polityk HCL i tokenów z ograniczonym TTL. W SOPS — definiując osobne klucze age dla różnych środowisk (dev, staging, prod) i odpowiednie reguły w .sops.yaml.

Automatyczna rotacja sekretów

Statyczne hasła to tykająca bomba zegarowa. Każdy, kto pracował wystarczająco długo w DevOps, widział sytuację, gdy hasło ustawione „na chwilę" żyło na produkcji latami. Dynamiczne sekrety Vault z krótkim TTL (1–24 godziny) eliminują ten problem w warstwie baz danych i usług chmurowych.

Dla sekretów przechowywanych w plikach SOPS ustal harmonogram rotacji kluczy age co 90 dni i automatyzuj proces za pomocą sops updatekeys.

Audyt i monitoring

# Włącz audit log w Vault/OpenBao
vault audit enable file file_path=/var/log/vault/audit.log

# Każda operacja na sekretach zostanie zalogowana w formacie JSON
# Przykładowy wpis:
# {
#   "type": "response",
#   "auth": {"token_type": "service", "policies": ["app-team"]},
#   "request": {"path": "apps/data/produkcja/baza-danych", "operation": "read"},
#   "response": {"data": {"...": "HMAC-SHA256:abc123..."}}
# }

Warto tu zauważyć, że Vault nie loguje samych wartości sekretów — zamiast tego używa HMAC-SHA256 do ich maskowania. Dzięki temu logi audytowe są bezpieczne nawet w razie ich wycieku, a jednocześnie pozwalają wykryć wzorce dostępu (np. nietypowe godziny czy nieznane adresy IP).

Ochrona przed wyciekiem sekretów

• Używaj narzędzi takich jak GitGuardian, TruffleHog lub gitleaks do skanowania repozytoriów w poszukiwaniu przypadkowo umieszczonych sekretów
• Skonfiguruj pre-commit hooki blokujące commit plików zawierających wzorce kluczy API
• Włącz GitHub Secret Scanning lub GitLab Secret Detection w swoich repozytoriach
• Nigdy nie loguj wartości sekretów — Vault automatycznie maskuje je w audit logach za pomocą HMAC

Bezpieczeństwo kluczy szyfrujących

• Klucze prywatne age nigdy nie powinny znaleźć się w repozytorium Git (to brzmi oczywiste, ale wciąż się zdarza)
• W CI/CD przechowuj klucz age jako zaszyfrowaną zmienną — np. GitHub Secrets albo GitLab CI Variables
• W środowisku produkcyjnym rozważ przechowywanie kluczy w sprzętowym module HSM lub usłudze KMS w chmurze (AWS KMS, GCP KMS, Azure Key Vault)
• Dla Vault/OpenBao używaj mechanizmu Auto Unseal z backendem KMS zamiast ręcznego Shamir unseal

Porównanie narzędzi — które wybrać?

Kryterium	SOPS + age	HashiCorp Vault	OpenBao
Złożoność wdrożenia	Niska — jeden plik binarny	Wysoka — klaster HA, Raft, unseal	Wysoka — jak Vault
Dynamiczne sekrety	Nie	Tak	Tak
Kontrola dostępu	Na poziomie kluczy age	Polityki HCL, tokeny, role	Polityki HCL, tokeny, role
Audit log	Brak (historia Git)	Pełny audit trail	Pełny audit trail
Koszt infrastruktury	Zerowy	Serwer(y) + licencja BSL	Serwer(y), brak opłat licencyjnych
GitOps-ready	Natywne	Przez External Secrets Operator	Przez External Secrets Operator
Idealne dla	Małe zespoły, GitOps, CI/CD	Duże organizacje, multi-cloud	Organizacje wymagające open source

Wiele zespołów DevOps w 2026 roku stosuje podejście hybrydowe — i moim zdaniem to najrozsądniejsza droga. SOPS + age do szyfrowania konfiguracji statycznych w repozytorium, a Vault lub OpenBao do dynamicznego generowania krótkoterminowych poświadczeń. Takie połączenie zapewnia bezpieczeństwo na każdym etapie, od commitowania kodu po runtime w produkcji.

Często zadawane pytania (FAQ)

Czy SOPS jest bezpieczny do przechowywania sekretów w publicznym repozytorium Git?

Tak, pod warunkiem poprawnej konfiguracji. SOPS szyfruje wartości za pomocą AES-256-GCM, a klucz szyfrowania danych (DEK) jest chroniony przez klucz age lub KMS. Atakujący musiałby zdobyć klucz prywatny age lub dostęp do usługi KMS, żeby odszyfrować wartości. Niemniej, przechowywanie sekretów w publicznym repozytorium zwiększa powierzchnię ataku — jeśli to możliwe, preferuj repozytoria prywatne i koniecznie dodaj pre-commit hooki weryfikujące stan szyfrowania.

Jak przeprowadzić migrację z HashiCorp Vault do OpenBao?

OpenBao zachowuje pełną kompatybilność API z Vault, więc migracja zazwyczaj sprowadza się do czterech kroków: (1) eksport danych z Vault za pomocą vault kv get lub snapshot Raft, (2) uruchomienie serwera OpenBao z identyczną konfiguracją (zamień vault na bao w plikach HCL), (3) import danych, (4) zaktualizowanie zmiennych środowiskowych klientów z VAULT_ADDR na BAO_ADDR. Polityki HCL i tokeny są w pełni kompatybilne.

Jakie są najczęstsze błędy przy zarządzaniu sekretami na Linuksie?

Najczęstsze błędy to: przechowywanie sekretów w postaci jawnej w plikach .env commitowanych do Git, używanie jednego klucza lub hasła w wielu środowiskach, brak rotacji kluczy i haseł, nadmiarowe uprawnienia (np. wszystkie usługi korzystają z tego samego tokena root Vault) oraz brak automatycznego skanowania repozytoriów w poszukiwaniu wyciekniętych sekretów.

Czy mogę używać SOPS z kluczami SSH zamiast age?

Tak, age obsługuje klucze SSH (ed25519 i RSA) jako odbiorców szyfrowania. Możesz zaszyfrować plik za pomocą sops --encrypt --age $(ssh-to-age < ~/.ssh/id_ed25519.pub). Jednak dedykowane klucze age są zalecane w środowiskach produkcyjnych, ponieważ zapewniają lepszą separację odpowiedzialności i łatwiejszą rotację niezależną od kluczy SSH.

Jak zintegrować Vault/OpenBao z Kubernetes bez hardkodowania tokenów?

Najlepsza metoda to użycie Kubernetes auth method w Vault/OpenBao, która uwierzytelnia pody na podstawie ich Service Account Token. Alternatywnie możesz użyć External Secrets Operator (ESO) — kontrolera Kubernetes, który automatycznie synchronizuje sekrety z Vault/OpenBao do natywnych obiektów Kubernetes Secret. W obu przypadkach eliminujesz potrzebę ręcznego zarządzania tokenami w podach.