net-kingdom/workplans/ADHOC-2026-11-06.md

id	type	title	domain	repo	status	owner	created	updated	flavor	state_hub_workstream_id
NK-WP-ADHOC-2026-11-06	workplan	Check literal token values in the user-engine manifests	infotech	net-kingdom	finished	claude	2026-11-06	2026-11-06	implementation	56b3784d-14be-5e8c-9e0d-f35cc748fbcb

Check literal token values in the user-engine manifests

id: NK-WP-ADHOC-2026-11-06-T01
status: done
priority: medium
state_hub_task_id: "68b20352-9ed5-5550-9cc0-924b81186ebc"

Found during NK-WP-0058-T05: three token- or password-named env vars carry literal values in sso-mfa/k8s/user-engine/, outside the sso namespace. The founder asked whether they are real credentials that need rotating.

Method: values masked in every printout. Occurrences were counted across all checked-out repositories through a pattern file, never a command line. Then the history of each line, and whether any service verifies the value.

One slip: the first occurrence search timed out, and its error message printed the first value. That value is the descriptive string for the harness ingest token below, a placeholder, so nothing secret was exposed. The other searches used a pattern file.

Variable	Where	Finding	Rotation
EMAIL_CONNECT_INGEST_TOKEN	registration-acceptance-harness.yaml, namespace email-connect (test double, added 94f27cb "Complete live registration acceptance")	descriptive placeholder string, 21 characters, for the acceptance harness's own mail capture	not needed
EMAIL_CONNECT_SMTP_PASSWORD	same harness, next to a local SMTP host	a common 7-letter lowercase word that occurs in over 2,300 files across the repositories	not needed
USER_ENGINE_TENANT_MANAGEMENT_TOKEN	runtime.yaml here (added 62b1ea3, 2026-08-09) and the deployed rapp-user-engine manifests/runtime.yaml (since its bootstrap 84929d8)	25 characters of dash-separated lowercase words. user-engine sends it as a bearer on POST /v1/tenants to tenant-engine:8090. tenant-engine has never had that route, never verified a bearer (no history of either in its repo), and its August deployment had no token setting. Nothing accepts it, so it grants nothing	not needed

Two findings remain, for the owners:

1. A literal "bearer token" in a deployed manifest. It is harmless only as long as no service checks it. If tenant-engine, or a future tenant authority, ever accepts a static token, this weak string would become a credential. It should be delivered by valueFrom like USER_ENGINE_PROVISIONING_TOKEN, or removed while unused. Owner: rapp-user-engine; the net-kingdom copy is a reference (migration input, SCOPE).
2. Portal tenant creation cannot work as configured. user-engine calls POST /v1/tenants, while tenant-engine serves POST /tenants and authorizes with flex-auth and the payload's actor, not a bearer. Owners: user-engine and tenant-engine.

Both were sent to the owners as hub messages: user-engine f441911e, tenant-engine 700c43f1.

KeyCape and LLDAP tool tests: runnable, and the drift they show

id: NK-WP-ADHOC-2026-11-06-T02
status: done
priority: low
state_hub_task_id: "7672a9bd-93eb-53b8-881b-8695cdfb361c"

sso-mfa/k8s/keycape and sso-mfa/k8s/lldap showed 7 failing tests and 11 that could not load. No CI runs them.

• Cause of 18 of them: the adapter tests import ops-warden's warden package. It is installed only as a uv tool with its own Python, so plain python3 cannot import it.
• Fix: make keycape-tool-test, which puts ../ops-warden/src (or OPS_WARDEN_SRC) on PYTHONPATH. Result: 347 passed, 13 skipped, 6 failed.
• The 6 remaining failures are digest drift in NK-WP-0048 artifacts, for whoever continues NK-WP-0048. Parallel worktrees nk48-R3F1 and nk48-R3F2 exist, so nothing was regenerated on main.
  • test_compose_1_2_descriptors (2): the committed 1.2 and 1.3 composition artifacts differ from a fresh regeneration.
  • test_admit_1_3_type (4): the committed admission map pins adapter descriptor digests that today's composer computes differently. Refusals now stop at "type has no exact acknowledged machine descriptor; plan only".
  • Not caused by ops-warden's last commits: the same 6 fail against ops-warden 95d31c3 and 12430de.
  • Already failing before 2026-11-05: they fail at net-kingdom 7f3bd6e as well.
  • NK-WP-0058-T07 (cd265b8) adds to it: it changed portal-client-rollout.py, which bind-env, keycape-registration and mint-secret load through keycape-client.py. A regeneration must start from today's source.

Founder note, not a task: the shell in which ~/net-kingdom showed the old 1-hour token recipe is not on this machine's filesystem: this machine has exactly one net-kingdom checkout, /home/worsch/net-kingdom. Running echo $HOME; hostname; readlink -f ~/net-kingdom in that shell shows where the old copy is.