Skip to content

Grant the platform identity its cluster relation - #18

Merged
vitramir merged 2 commits into
mainfrom
platform-identity-grant
Aug 9, 2026
Merged

vitramir merged 2 commits into
mainfrom
platform-identity-grant

Conversation

@vitramir

@vitramir vitramir commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

The admin relation on cluster:global for the platform admin identity was written straight to OpenFGA by install glue. Nothing owned it, so nothing recreated it when it was lost, and no service could say why it existed.

It is granted here now, when an identity registers as IDENTITY_TYPE_PLATFORM, because that grant is intrinsic to the type: a platform identity is a cluster admin by definition. The Gateway re-registers on every start and the grant converges on each one, so a tuple lost out from under it is repaired without an operator.

Installs that predate the type carry this identity as a user, and nothing else would ever correct the row — so an existing record is adopted. Only from the user type: anything else under that ID belongs to someone, and adopting a runner would hand it cluster admin.

Needs agynio/api#180. Pairs with agynio/gateway#204 — that PR resolves the token to the type this one acts on. Part of one-step-install.

The admin relation on cluster:global for the platform admin identity was
written straight to OpenFGA by install glue. Nothing owned it, so nothing
recreated it when it was lost, and no service could say why it existed.

It is granted here now, when an identity registers as IDENTITY_TYPE_PLATFORM,
because that grant is intrinsic to the type: a platform identity is a cluster
admin by definition. The Gateway re-registers on every start and the grant
converges on each one, so a tuple lost out from under it is repaired without an
operator.

Installs that predate the type carry this identity as a user, and nothing else
would ever correct the row -- so an existing record is adopted. Only from the
user type: anything else under that ID belongs to someone, and adopting a
runner would hand it cluster admin.

Refs architecture/changes/2026-08-08-one-step-install.md
CI generated the bindings from an api feature branch that was merged and
deleted long ago, so it has been building against a snapshot of the schema
rather than the schema. Anything added since is simply absent, which reads as
the change being wrong rather than the input being stale.

Every other service repo generates from buf.build/agynio/api.
@vitramir
vitramir merged commit d49ffd3 into main Aug 9, 2026
1 of 2 checks passed
@vitramir
vitramir deleted the platform-identity-grant branch August 9, 2026 01:02
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