Skip to content

Own the platform identity here instead of granting it on request - #19

Merged
vitramir merged 1 commit into
mainfrom
platform-identity-owned-by-identity
Aug 9, 2026
Merged

vitramir merged 1 commit into
mainfrom
platform-identity-owned-by-identity

Conversation

@vitramir

@vitramir vitramir commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #18, which got this wrong twice over.

It was reachable over the wire. Every service calls RegisterIdentity, so any of them could name IDENTITY_TYPE_PLATFORM and hand itself admin on cluster:global. The grant now names exactly one identity, read from this service's own PLATFORM_IDENTITY_ID, and nothing can ask for it.

It made the Gateway responsible for a fact it does not own. The Gateway triggered the grant by re-registering the identity at startup, which meant a retry loop in its main() — convergence inside a single run, which is the shape one-step-install exists to remove.

Both halves belong here: the record and the relation are what this service owns, so it converges them at its own startup. Retrying against the authorization service is ordinary startup behaviour rather than a provisioning step — nothing waits on it and every request is served meanwhile.

RegisterIdentity goes back to being a registry write. Pairs with the matching simplification in agynio/gateway#204.

Granting cluster admin inside RegisterIdentity was wrong twice over.

It was reachable over the wire: every service calls RegisterIdentity, so any
of them could name the platform type and hand itself admin on cluster:global.
The grant now names exactly one identity, read from this service's own
configuration, and nothing can ask for it.

It also made the Gateway responsible for a fact it does not own. The Gateway
triggered the grant by re-registering the identity at startup, which meant a
retry loop in its main() -- convergence inside a single run, which is the shape
this whole change set exists to remove.

Both halves belong here: the record and the relation are what this service
owns, so it converges them at its own startup. Retrying against the
authorization service is ordinary startup behaviour rather than a provisioning
step -- nothing waits on it, and every request is served meanwhile.

RegisterIdentity goes back to being a registry write.

Refs architecture/changes/2026-08-08-one-step-install.md
@vitramir
vitramir merged commit cd08ec9 into main Aug 9, 2026
1 of 2 checks passed
@vitramir
vitramir deleted the platform-identity-owned-by-identity branch August 9, 2026 01:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant