feat(db): authentik_mendys allocation for the MendysRobotics identity silo - #421
Merged
Merged
Conversation
…Robotics IdP silo
MendysRobotics gets its own Authentik instance (deployed by the FuzeFront
chart) rather than a brand/provider on the shared FuzeFront directory, so
its accounts are genuinely separate: a FuzeFront account is not recognised
by the Mendys apps and vice versa, and the same email may exist in both.
Authentik has no realm. One instance = one user directory; brands are
branding + default flows only ("all objects like applications and providers
are still global"). Schema-per-tenant hard tenancy exists from 2024.2 but is
Enterprise-only, alpha, licensed per tenant and API-managed — incompatible
with the blueprint/GitOps model. A second instance on its own database gives
the same isolation for free and stays declarative.
Adds the `authentik-mendys` serviceDatabases entry (role
authentik_mendys_user, database authentik_mendys) to the base and Contabo
values, plus the allocation registry row. Gated OFF in both: per
governance/datastore-provisioning.md the gate flips only in the PR that
lands the strict-scoped `authentik-mendys-db-credentials` SealedSecret for
the fuzeinfra namespace. No credential is generated or committed here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session-Id: 55a394fa-d5ba-4da4-b41f-b0ef56fa6ddf
… silo authentik keeps cache + sessions in Redis under non-namespaced key names, so the Mendys instance must not share index 0 with the FuzeFront authentik. An ACL user is not applicable here — authentik owns its key layout and does not prefix keys, so there is nothing to scope a prefix ACL to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session-Id: 55a394fa-d5ba-4da4-b41f-b0ef56fa6ddf
izzywdev
changed the title
This was referenced Jul 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Declares the Postgres allocation backing a second Authentik instance for MendysRobotics, deployed by the FuzeFront chart.
Companion PR: izzywdev/FuzeFront#428
Why a separate database
MendysRobotics needs its own set of accounts — a FuzeFront user must not be recognised by the Mendys apps, and vice versa.
Authentik has no realm. One instance is one user directory, and brands (
authentik_brands.brand) are branding + default flows only — per authentik's docs, "all objects like applications and providers are still global". Hard tenancy (a Postgres schema per tenant, 2024.2+) does give real separation, but it is Enterprise-only, still alpha, requires a license per tenant, and is created only through the API — so it cannot be expressed as a blueprint in git, which is how every other authentik object is managed here.A second instance on its own database gives the same isolation property for free and stays fully declarative.
Changes
serviceDatabasesentryauthentik-mendys→ roleauthentik_mendys_user, databaseauthentik_mendys, invalues.yamlandvalues-contabo.yaml. Provisioned by the existingfuzeinfra-service-db-provisionPostSync Job — nothing imperative.governance/datastore-allocations.md: Postgres row + Redis index row.Redis index 2 is claimed deliberately. Authentik stores cache and sessions under non-namespaced key names, so the Mendys instance must not share index 0 with the FuzeFront authentik (which uses authentik's default of 0) — they would collide and leak session state across the very boundary this split exists to create. An ACL user is not applicable here: authentik owns its key layout and does not prefix keys, so there is nothing to scope a prefix ACL to.
Gated OFF in both values files — on purpose
Per
governance/datastore-provisioning.md, the gate flips only in the PR that lands the strict-scopedauthentik-mendys-db-credentialsSealedSecret (keypassword) for thefuzeinfranamespace. FuzeFront owns that password (its Authentik pods connect with it) and seals it into both namespaces. Flipping this totruebefore that Secret exists fails the PostSync Job.No credential is generated or committed in this PR.
Verification
serviceDatabasesparses correctly in both values files and the new entry is present and disabled in each. Chart behaviour is unchanged while gated off.🤖 Generated with Claude Code