key-cape/workplans/KEY-WP-0045-service-identity-facts-export.md
tegwick a1ab8ff807
Some checks failed
Authentication acceptance / acceptance (push) Failing after 1m12s
Authentication acceptance / provider-contract (push) Successful in 23s
Build and Publish Container Image / build-and-push (push) Successful in 40s
KEY-WP-0045: value-safe identity-facts export for NK-WP-0054-T04
keycape identity-facts --config PATH and make identity-facts print client
registry, directory bind and admin-surface facts without credential values or
secret reference names. Fixture and committed-config tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 308701@bnt-lap001
Assistant-Session: 5548e447-444c-4dcc-bed1-05c16eebfe56
2026-10-28 09:50:54 +01:00

71 lines
2.5 KiB
Markdown

---
id: KEY-WP-0045
type: workplan
title: "Value-safe identity facts export for the service-identity conformance check"
domain: infotech
repo: key-cape
status: active
owner: claude-code
topic_slug: custodian
created: "2026-10-28"
updated: "2026-10-28"
flavor: extension
depends_on: []
---
Accepted from net-kingdom NK-WP-0054-T04 (State Hub message 74fdd863). NetKingdom's
`tools/service-identity/validate.py` compares declared identity facts with observed
ones under `canon/standards/service-identity-privilege_v0.1.md`; KeyCape supplies the
observed side as non-secret metadata. Nothing here reads a Secret, changes a live
deployment or registers anything.
## Export identity facts from a KeyCape config
```task
id: KEY-WP-0045-T01
status: done
priority: high
```
`keycape identity-facts --config PATH` (`src/cmd/keycape/identityfacts.go`) and
`make identity-facts [IDENTITY_CONFIG=path]` print schema
`keycape-identity-facts/v0.1`: per client the id, principal type, client type, grant
types, access-token audience (and whether it is registered or the client-id
default), scopes, service subject, tenant, roles, lifetime, MFA requirement and the
credential *kind*; the LLDAP bind DN, base DN and whether the bind is the directory
administrator; the privacyIDEA and Authelia credential kinds; and the fixed admin
surfaces. Credential fields and secret reference names are never copied. Tests:
`src/cmd/keycape/identityfacts_test.go` over a canary fixture and the committed
`config/service-clients.example.yaml`.
## Live view of the deployed registry
```task
id: KEY-WP-0045-T02
status: wait
priority: medium
```
The deployed config is the `config.yaml` key of Secret `sso/keycape-config`, and the
running image is distroless and predates this subcommand, so an agent cannot produce
the live view. Founder-run, streaming the config through the exporter without
writing it to disk:
kubectl -n sso get secret keycape-config -o jsonpath='{.data.config\.yaml}' \
| base64 -d | (cd ~/key-cape/src && go run ./cmd/keycape identity-facts --config /dev/stdin) \
> ~/keycape-identity-facts.live.json
The output is value-safe and can be handed to NetKingdom. Waiting on the founder.
## Directory bind identity
```task
id: KEY-WP-0045-T03
status: todo
priority: medium
```
The NetKingdom reference config binds LLDAP as `uid=admin,ou=people,...`, the
directory administrator; KeyCape only needs read access (`internal/adapters/lldap`).
A read-only bind account is a cross-repo change (LLDAP owner, custody, rollout) and
needs a NetKingdom/founder decision before any work.