Repository navigation
feat(comet_eks): byo_s3_irsa_roles — customer bring-your-own-S3 IAM (DND-1423) - #48
Merged
Merged
Conversation
… (DND-1423) Add a reusable, opt-in `byo_s3_irsa_roles` map that provisions the IAM that accompanies a customer-supplied S3 bucket: one IRSA role + a scoped customer-managed policy + attachment per map entry. The trusted Kubernetes ServiceAccounts (the IRSA :sub condition) are an explicit input, so the trust list is codified and reviewable in PRs. This generalizes the BYO-S3 access role that was previously created out-of-band during onboarding (e.g. Zoox's ZooxS3Access), whose invisible trust list let a missing ServiceAccount silently break ClickHouse remote backups for >=7 days (DND-1413). It follows the existing Loki IRSA triplet exactly and reuses the upstream iam-role-for-service-accounts-eks module to build the web-identity trust. - Permissions are scoped to the supplied bucket ARN(s) by default (not s3:::*), so the feature is least-privilege from day one. - role_name_override / policy_name_override let an existing out-of-band role or policy be adopted in place via `terraform import` (stable ARN -> IRSA annotations keep working) instead of being recreated. - Empty map default -> no effect on any existing consumer. New MINOR (new feature family): release as v1.21.0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…423 PR review) Address Baz review on PR #48. The variable only length-checked its lists, so malformed inputs passed `terraform validate` and failed at apply (or silently produced broken IAM/IRSA): - bucket_arns: require an exact `arn:aws:s3:::<bucket>` per entry — reject wildcards (`arn:aws:s3:::*`, which would reintroduce the over-broad grant this feature exists to remove) and trailing `/*`/object keys (main.tf already appends `/*`, so a trailing glob yields `<bucket>/*/*`). - namespace_service_accounts: require `<namespace>:<sa-name>` — a malformed subject silently produces a trust condition no pod can satisfy. - policy_name_override: add IAM policy-name validation (1-128 chars) for parity with the existing role_name_override check. Verified the regexes accept the intended Zoox values and reject the bad cases; `terraform validate` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
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.
User description
What
Adds a reusable, opt-in
byo_s3_irsa_rolesmap to the module. Each entry provisions the IAM that accompanies a customer-supplied S3 bucket:It follows the existing Loki IRSA triplet exactly (
data.aws_iam_policy_document→aws_iam_policy→module ... iam-role-for-service-accounts-eks ~> 5.39), so the OIDC:sub/:audtrust is built by the upstream module fromnamespace_service_accounts.Why
Generalizes the BYO-S3 access role that was previously created out-of-band during onboarding (e.g. Zoox's
ZooxS3Access). Because that role's trusted-SA list lived only in live AWS and not in code, a missing ServiceAccount went unreviewed and silently broke ClickHouse remote backups for ≥7 days (DND-1413). Codifying it makes the trust list reviewable in PRs, and any future BYO-S3 customer gets the same primitive from day one instead of a hand-rolled role.Design notes
arn:aws:s3:::*.role_name_override/policy_name_overridelet an existing out-of-band role/policy be adopted viaterraform importwithout recreation (stable ARN → IRSA annotations keep working).Testing
terraform init -backend=false+terraform validate→ "the configuration is valid" (only pre-existing deprecation warnings, unrelated to this change).terraform fmtclean.Release
New MINOR (new feature family) — tag v1.21.0 after merge.
Follow-up (separate PRs, not here)
?ref→ v1.21.0 and adoptZooxS3Accessonto this feature viabyo_s3_irsa_roles+ import blocks (normalize-on-adopt: trims the out-of-band node-role /s3.amazonaws.com/ ad-hoc-user trust statements and scopes perms to the bucket).Ref: DND-1423 (follow-up to DND-1413).
🤖 Generated with Claude Code
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Add a new
byo_s3_irsa_rolesinput to the rootcomet_eksmodule and itsmodules/comet_eksimplementation to provision per-bucket IRSA roles, customer-managed S3 policies, and policy attachments for customer-supplied buckets. Generalize the existingiam-role-for-service-accounts-eksflow sonamespace_service_accountsdrive OIDC trust while keeping ClickHouse backup access scoped and opt-in.aws_iam_policy_document,aws_iam_policy, andiam-role-for-service-accounts-eks.Modified files (3)
Latest Contributors(2)
Modified files (1)
Latest Contributors(2)