jerry/buzz
1
0
Fork 0
mirror of https://github.com/block/buzz.git synced 2026-10-28 13:01:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clarify deletion job workload identity

Browse Source 
Distinguish the disabled Kubernetes API token mount from provider workload-identity credentials while retaining the dedicated service-account recommendation.

Co-authored-by: Codex <noreply@openai.com>
Signed-off-by: tornquist <tornquist@squareup.com>
This commit is contained in:
tornquist
2026-09-28 13:25:59 +00:00
parent 10372630dc
commit 7e3e142e63
2 changed files with 15 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
deploy/charts/buzz/README.md
View File

@@ -125,8 +125,10 @@ checkpoints remain the execution authority.
The pod receives only `DATABASE_URL`, `REDIS_URL`, and required S3
configuration/credential variables. It does not receive the relay private key,
git-hook secret, relay URL, service-account token, service links, or a generic
environment registry. Schedule,
git-hook secret, relay URL, service links, or a generic environment registry.
The chart disables the ordinary Kubernetes API service-account token mount;
platform workload-identity admission may still inject its own projected token
and provider environment variables. Schedule,
deadline, history, termination grace, resources, service account, pod labels,
and pod annotations are independently configurable under
`operatorJobs.deletionDrain`.

20
docs/operator-community-deletion.md
View File

@@ -49,17 +49,19 @@ non-secret S3 settings. It does not receive `BUZZ_RELAY_PRIVATE_KEY`,
`BUZZ_GIT_HOOK_HMAC_SECRET`, `RELAY_URL`, or the full Secret through `envFrom`.
The pod also disables service-account token automounting and Kubernetes service
link environment injection because the executor does not call the Kubernetes
API or discover cluster Services.
API or discover cluster Services. This disables the ordinary Kubernetes API
token mount, not credentials injected by a platform workload-identity
mechanism.
Leaving `operatorJobs.deletionDrain.serviceAccountName` empty falls back to the
relay's own service account. `automountServiceAccountToken: false` only
suppresses the projected token inside the pod; it does not detach the identity.
Cloud IAM bindings attached to that service account — IRSA on EKS, Workload
Identity on GKE — are resolved by the node/metadata path and still apply, so the
drain pod inherits the relay's cloud permissions. Create a dedicated service
account with only the object-store permissions listed below and name it
explicitly if you want the executor's IAM blast radius to be smaller than the
relay's.
relay's own service account, including cloud IAM attached through the platform's
workload-identity mechanism. For example, the EKS IRSA admission webhook can
inject its projected web-identity token and AWS environment variables despite
`automountServiceAccountToken: false`; other platforms provide their own
identity mechanism. The drain pod therefore inherits the relay's cloud role by
default. Create a dedicated service account with only the object-store
permissions listed below and name it explicitly if you want the executor's IAM
blast radius to be smaller than the relay's.
The S3 principal needs the relay's normal object permissions plus bucket-level
`s3:ListBucketVersions` and object-level `s3:DeleteObjectVersion` for every