feat(provisioner): per-org ServiceAccount for Lakekeeper pods (PR6)#584
Merged
Conversation
fuziontech
force-pushed
the
lakekeeper-pr3-provisioning-trigger
branch
from
8a76b67 to
5e5ac44
Compare
Each org's Lakekeeper now runs under its own ServiceAccount (lakekeeper-<orgid>) in the shared `lakekeeper` namespace, so it can carry a distinct EKS Pod Identity scoped to that org's S3 bucket — per-org cloud- identity isolation without one namespace per org. - EnsureServiceAccount creates the bare per-org SA (idempotent; leaves an existing SA untouched so out-of-band annotations survive). No IRSA role-arn annotation: EKS Pod Identity binds the role to (namespace, SA) AWS-side. - LakekeeperServiceAccountName(orgID) is the naming convention the posthog-cloud-infra Pod Identity association keys on. - EnsureForOrg creates the SA before the CR (step 2c). - EnsureCR renders spec.serviceAccountName (the PostHog-fork operator field); omitted when empty so it stays backward compatible with the stock operator. Depends on PostHog/lakekeeper-operator@7a637da (charts #11192) for the serviceAccountName CRD field; the stock operator ignores the field. Tests: SA create + idempotency + bad-orgID rejection; CR renders/omits serviceAccountName. go test -tags kubernetes ./controlplane/... green; lint clean. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
fuziontech
force-pushed
the
lakekeeper-pr6-per-org-sa
branch
from
798868c to
3b2a9ac
Compare
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.
What & why
Gives each org's Lakekeeper its own Kubernetes ServiceAccount (
lakekeeper-<orgid>) in the sharedlakekeepernamespace, so each can carry a distinct EKS Pod Identity scoped to that org's S3 bucket — per-org cloud-identity isolation without one namespace per org.This is the duckgres half of the per-org-identity decision. The operator half is the
spec.serviceAccountNamepatch on PostHog's operator fork (charts #11192); the AWS half is per-org Pod Identity associations (posthog-cloud-infra, follow-up; ECR repo in posthog-cloud-infra #8191).Changes
EnsureServiceAccount— creates the bare per-org SA. Idempotent; on re-run leaves an existing SA untouched so out-of-band annotations survive. No IRSA role-arn annotation — EKS Pod Identity binds the IAM role to the(namespace, serviceAccount)pair AWS-side.LakekeeperServiceAccountName(orgID)— the naming convention the Pod Identity association keys on.EnsureForOrgcreates the SA (step 2c) before the CR.EnsureCRrendersspec.serviceAccountName; omitted when empty, so it's backward compatible with the stock upstream operator.Compatibility
Depends on
PostHog/lakekeeper-operator@7a637da(charts #11192) for theserviceAccountNameCRD field. The stock operator ignores the field, so this is safe to land ahead of the operator rollout.Testing
serviceAccountName.go test -tags kubernetes ./controlplane/...green; lint clean.🤖 Generated with Claude Code