feat(chart): add serviceAccountName support at per-agent and global level

[antigenius0910]

Summary

• Adds serviceAccountName at chart-global ($.Values.serviceAccountName) and per-agent (agents.<name>.serviceAccountName) level
• Per-agent value wins when set; otherwise falls back to chart-global. Both empty preserves current behaviour (no serviceAccountName rendered → Kubernetes uses cluster default SA) — zero impact on existing users
• Required to activate IRSA on EKS: without an explicit serviceAccountName, the pod-identity-webhook never injects AWS credentials and workloads silently fall back to the broad EC2 node role, breaking least-privilege
• Scope: string reference to an existing ServiceAccount only. The chart does NOT create a new SA or manage IRSA annotations (operators provision out-of-band via Terraform / IDP / kubectl) — matches how PR feat(openab): add existingSecret support for Slack agent credentials #901 (existingSecret) and feat(chart): add imagePullSecrets support at per-agent and global level #910 (imagePullSecrets) reference existing K8s resources

Closes #913

Discord discussion: https://discord.com/channels/1491295327620169908/1491365157010542652/1507736112913973268

Changes

File	Purpose
charts/openab/values.yaml	Add chart-global serviceAccountName: "" + per-agent serviceAccountName: "" on the kiro agent
charts/openab/templates/deployment.yaml	Render serviceAccountName after securityContext using default $.Values.serviceAccountName $cfg.serviceAccountName; if guards against empty value to preserve current "no field rendered" behaviour
charts/openab/README.md	Document both values in the Common Values tables
charts/openab/tests/serviceaccount_test.yaml	6 helm-unittest cases covering default / global-only / per-agent-only / per-agent-wins / empty-fallback / both-empty

Test plan

• helm unittest charts/openab — all 113 tests pass (6 new + 107 existing)
• helm lint charts/openab — clean
• helm template testrelease charts/openab --set serviceAccountName=openab-sa renders serviceAccountName: openab-sa at pod spec level
• helm template with no values set renders no serviceAccountName field (backwards-compat verified)

Out of scope (possible follow-ups)

• automountServiceAccountToken: false for agents that don't need K8s API access
• Chart-managed SA creation with IRSA annotations / labels / ClusterRoleBindings — larger surface, separate RFC if there's demand

Note on diff context

This branch is based on a slightly older fork main, so the diff context does not include PR #911 (imagePullSecrets) which is still in review. Once #911 merges, this PR's new serviceAccountName block will sit immediately before the imagePullSecrets block (both pod-level identity/credential fields grouped together) — no conflict expected.

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: feat(chart): add serviceAccountName support at per-agent and global level
• Source: feat(chart): add serviceAccountName support at per-agent and global level #914
• Status: moved to PR-Screening
• Generated at: 2026-05-23T18:07:07.952Z
• Discord thread: not available

Screening report

## Intent

PR #914 adds Helm chart support for setting an existing Kubernetes serviceAccountName globally or per agent. The operator-visible problem is EKS IRSA and other workload-identity setups: without an explicit ServiceAccount reference, pods use the namespace default service account, so identity webhooks may not inject least-privilege credentials.

Feat

Feature work. It adds a chart-level serviceAccountName default, an agent-level override, deployment template rendering, README entries, and helm-unittest coverage. Empty values preserve current behavior by omitting the pod spec field.

Who It Serves

Deployers and agent runtime operators, especially teams running OpenAB on EKS or other Kubernetes clusters where pod identity is bound to named ServiceAccounts.

Rewritten Prompt

Implement Helm chart support for referencing an existing Kubernetes ServiceAccount from OpenAB agent pods. Add serviceAccountName to chart-global values and to each agent config, with the per-agent value taking precedence over the global value. Render spec.serviceAccountName only when the resolved value is non-empty, so existing installs keep using Kubernetes defaults. Document both values and add helm-unittest cases for no value, global-only, per-agent-only, per-agent-wins, empty per-agent falling back to global, and both empty.

Merge Pitch

This is a narrow chart feature with clear operational value and low migration risk. It improves least-privilege deployments without requiring the chart to create or own ServiceAccounts, IAM annotations, or RBAC. The main reviewer concern should be template precedence and whether the README makes the scope explicit enough: this references an existing ServiceAccount only.

Best-Practice Comparison

OpenClaw and Hermes Agent patterns around scheduling, durable jobs, isolated executions, routing, retry, locking, and run logs do not apply directly. This PR is Kubernetes deployment configuration, not runtime scheduling or delivery orchestration.

The relevant best practice is closer to existing OpenAB chart conventions: reference externally managed Kubernetes resources by name, keep empty defaults backward-compatible, and test rendered manifests. This matches the direction of existingSecret and image pull secret support.

Implementation Options

1. Conservative: Merge the current reference-only implementation. Keep ServiceAccount creation, annotations, token automount, and RBAC out of scope.

2. Balanced: Merge reference-only support now, then add a follow-up for automountServiceAccountToken with global and per-agent controls. This helps operators disable token mounting for agents that do not need Kubernetes API access.

3. Ambitious: Add full chart-managed ServiceAccount creation with annotations, labels, optional RBAC, and IRSA examples. This is more complete for greenfield installs, but it substantially expands chart ownership and cloud-provider-specific documentation.

Comparison Table

Option	Speed	Complexity	Reliability	Maintainability	User Impact	Fit for OpenAB now
Conservative: reference existing ServiceAccount	High	Low	High	High	Medium	Best fit
Balanced: add token automount follow-up	Medium	Medium	High	Medium	High	Good next split
Ambitious: chart-managed SA/RBAC/IRSA	Low	High	Medium	Medium	High	Too broad for this PR

Recommendation

Move forward with the conservative implementation if the tests pass on the current branch after rebasing against nearby chart changes. Keep this PR scoped to serviceAccountName references, then consider a separate follow-up for automountServiceAccountToken. Do not fold chart-managed ServiceAccount creation or IRSA annotations into this PR; that should be a separate design discussion because it changes ownership boundaries.

Comment: #914 (comment)
Project action: moved PVTI_lADOEFbZWM4BUUALzgtm54Q to PR-Screening in https://github.com/orgs/openabdev/projects/1