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

> Trzy filary Security Plane — tożsamość, sekrety i policy-as-code — działają razem, self-hostowane i opisane jako kod, spełniając jednocześnie wymóg suwerenności i audytowalnej autonomii.

URL: https://eiac.dev/blog/security-plane-sekrety-tozsamosc-policy
Filar: Security-as-Code
Data: 2026-04-30
Tagi: security, secrets, identity, policy-as-code, agents

---

Security Plane przewija się przez całą serię — w [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) jako jedna z pięciu płaszczyzn, w [Deterministycznym szkielecie](/blog/deterministyczny-szkielet-adp) 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.

<div class="callout">
<strong>Teza</strong>
<p>Bezpieczeństwa nie da się „dokleić" na końcu. To płaszczyzna przecinająca wszystkie inne: jeśli tożsamość, sekrety i polityki są u obcego dostawcy lub poza kodem, ani suwerenność, ani audytowalna autonomia agentów nie są możliwe.</p>
</div>

## 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](https://openid.net/developers/how-connect-works/) przed wieloma źródłami: [LDAP](https://datatracker.ietf.org/doc/html/rfc4511), [SAML](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf), dostawcy zewnętrzni) dobrze sprawdza się [Dex](/katalog/dex); dla pełnego, headless serwera [OAuth2](https://oauth.net/2/)/OIDC — [Ory Hydra](/katalog/ory-hydra). Konfigurację trzymasz deklaratywnie:

```yaml
# 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](/katalog/vault) / [OpenBao](/katalog/openbao), a dla zespołów ceniących prostotę [Infisical](/katalog/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](/katalog/sops) z kluczem [age](/katalog/age). Klucze pozostają jawne, wartości zaszyfrowane:

```yaml
# 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](/katalog/argocd-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](/katalog/open-policy-agent)/Conftest, Checkov), a w klastrze jako admission control ([OPA Gatekeeper](/katalog/gatekeeper)). Przykład reguły wiążącej bezpieczeństwo z suwerennością:

```rego
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](/katalog/dex)/[Ory Hydra](/katalog/ory-hydra).
- **Krótkożyciowe poświadczenia** z [Vault](/katalog/vault)/[OpenBao](/katalog/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.

```hcl
# 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](/blog/deterministyczny-szkielet-adp): 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](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) i [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).

## 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.