Security Plane: sekrety, tożsamość i policy-as-code

Security Plane przewija się przez całą serię — w Suwerennym IDP jako jedna z pięciu płaszczyzn, w Deterministycznym szkielecie jako warunek bezpiecznej autonomii agentów. Tu poświęcam jej całą uwagę, bo to warstwa, na której najłatwiej się przewrócić. Teza spaja oba konteksty: w platformie suwerennej i agentowej root of trust musi być lokalny i deklaratywny — tożsamość, sekrety i polityki pod kontrolą organizacji, opisane jako kod, a nie rozsiane po konsolach dostawców.

Tożsamość: niezależny broker zamiast natywnego IAM

Poleganie na natywnym IAM dostawcy chmury (np. AWS IAM) przywiązuje perymetr tożsamości do tego konkretnego vendora — i łamie suwerenność. Wzorzec to niezależny broker tożsamości, self-hostowany, integrujący istniejące źródła logowania.

Dla brokera federującego (OIDC przed wieloma źródłami: LDAP, SAML, dostawcy zewnętrzni) dobrze sprawdza się Dex; dla pełnego, headless serwera OAuth2/OIDC — Ory Hydra. Konfigurację trzymasz deklaratywnie:

# Dex: jeden punkt OIDC przed wieloma źródłami (fragment)
issuer: https://auth.eiac.dev/dex
connectors:
  - type: ldap
    id: corp
    name: Active Directory
    config: { host: ldap.eiac.dev:636 }
staticClients:
  - id: argo-cd
    name: Argo CD
    redirectURIs: ["https://cd.eiac.dev/auth/callback"]

Efekt: jedno SSO dla całej platformy, niezależne od dostawcy infrastruktury.

Sekrety: self-hosted źródło prawdy

Natywne KMS chmury to kolejny wektor lock-inu. Architektura suwerenna mandatuje self-hostowany menedżer sekretów jako jedyne źródło prawdy dla kluczy, haseł i certyfikatów — np. Vault / OpenBao, a dla zespołów ceniących prostotę Infisical. Aplikacje pobierają sekrety dynamicznie, więc nigdy nie lądują w repo ani w proprietarnym vaultcie dostawcy.

Druga, komplementarna droga to szyfrowanie sekretów w Git (GitOps-friendly): SOPS z kluczem age. Klucze pozostają jawne, wartości zaszyfrowane:

# secrets.enc.yaml — wersjonowane w repo, wartości zaszyfrowane
db_password: ENC[AES256_GCM,data:9b1d…,tag:7f…]
api_token:   ENC[AES256_GCM,data:0c44…,tag:a1…]

W modelu GitOps sekrety wstrzykuje się do klastra dopiero przy synchronizacji — np. przez Argo CD Vault Plugin, który zamienia placeholdery na wartości z backendu. Wybór „SOPS vs serwer sekretów” to kompromis: SOPS jest prosty i w pełni w repo; serwer daje dynamiczne, krótkożyciowe poświadczenia i centralną rotację.

Policy-as-code: bramka, nie audyt

Trzeci filar to polityki egzekwowane automatycznie, opisane jako kod. W CI działają jako bramki (OPA/Conftest, Checkov), a w klastrze jako admission control (OPA Gatekeeper). Przykład reguły wiążącej bezpieczeństwo z suwerennością:

package eiac.security

deny contains msg if {
  input.kind == "Deployment"
  some c in input.spec.template.spec.containers
  not c.securityContext.readOnlyRootFilesystem
  msg := sprintf("kontener %q musi mieć readOnlyRootFilesystem", [c.name])
}

Ta sama polityka chroni zmianę człowieka i agenta — bo działa na artefakcie, nie na autorze. To właśnie czyni ją skalowalną przy wolumenie zmian generowanych maszynowo.

Nowy wymiar: tożsamość nie-ludzka dla agentów

Platforma agentowa dokłada wymóg, którego klasyczny IDP nie miał: agent musi mieć własną, ograniczoną tożsamość — nie działać z poświadczeniami człowieka, który go uruchomił. Bez tego autonomia jest nieaudytowalna („kto to zrobił?”) i ma zbyt szeroki promień rażenia. Wzorce:

• Tożsamość nie-ludzka z wąskim zakresem (co agent może dotknąć), brokerowana przez Dex/Ory Hydra.
• Krótkożyciowe poświadczenia z Vault/OpenBao, wydawane na czas zadania — nie statyczne sekrety.
• Izolacja workspace dla równoległych przebiegów agentów, by nie kolidowały i nie eskalowały uprawnień.
• Ślad i provenance — każda akcja agenta zalogowana, artefakty podpisane.

# Vault: krótkożyciowe poświadczenia dla agenta zamiast statycznego sekretu
path "database/creds/agent-readonly" {
  capabilities = ["read"]   # TTL np. 15 min, automatyczna rotacja
}

To domyka wątek z Deterministycznego szkieletu: bez tożsamości nie-ludzkiej i krótkożyciowych poświadczeń nie da się bezpiecznie podnieść poziomu autonomii.

Jak to się składa w całość

Trzy filary Security Plane działają razem: tożsamość mówi kto/co (ludzie i agenci), sekrety dają bezpieczny dostęp (dynamiczny, lokalny), policy-as-code egzekwuje co wolno (deklaratywnie, w bramce). Wszystkie trzy są self-hostowane i opisane jako kod — dzięki czemu spełniają jednocześnie wymóg suwerenności (lokalny root of trust) i wymóg audytowalnej autonomii (ślad, granice, prowienancja), o których pisaliśmy w kontekście DORA i AI Act.

Podsumowanie

Security Plane to nie zestaw dodatków, lecz płaszczyzna przecinająca platformę. Niezależny broker tożsamości, self-hostowane sekrety i policy-as-code lokalizują root of trust w organizacji, a tożsamość nie-ludzka rozszerza ten model na agentów. To fundament, na którym stoją zarówno suwerenność (kontrola nad każdą warstwą), jak i bezpieczna autonomia (audytowalne granice działania). Bez tej płaszczyzny reszta serii pozostaje teorią. Jak w homelab: dopóki nie ogarniesz lokalnego PKI, tożsamości i sekretów, każda „automatyzacja” powyżej stoi na piasku.