[Helm] Regression: ServiceAccount annotations are ignored in chart version 2.1.x

[sdumser]

Describe the bug
In version 2.1.x of the Helm chart, the ServiceAccount resource defined in templates/rbac.yaml ignores the serviceAccount.annotations value.

In version 1.x, the template included a block to render {{ .Values.serviceAccount.annotations }}. In the refactor to version 2.x, this block appears to have been omitted from the template, making it impossible to configure IRSA (IAM Roles for Service Accounts) via standard Helm values.

To Reproduce
Steps to reproduce the behavior:

1. Render the rbac.yaml template specifically, attempting to inject a test annotation:

   helm template test aws-secrets-manager/secrets-store-csi-driver-provider-aws \
     --version 2.1.1 \
     --set serviceAccount.annotations.test-annotation=true \
     --show-only templates/rbac.yaml

2. Inspect the output.

   • Expected: The metadata block should include the injected annotation:

     metadata:
       name: test-secrets-store-csi-driver-provider-aws
       namespace: default
       annotations:
         test-annotation: true
       labels:
         # ...

   • Actual: The annotations block is completely missing from the rendered output:

     metadata:
       name: test-secrets-store-csi-driver-provider-aws
       namespace: default
       labels:
         helm.sh/chart: secrets-store-csi-driver-provider-aws-2.1.1
         app.kubernetes.io/name: secrets-store-csi-driver-provider-aws
         app.kubernetes.io/instance: test
         app.kubernetes.io/managed-by: Helm
         app: secrets-store-csi-driver-provider-aws

Expected behavior
The annotations defined in values.yaml should be rendered onto the ServiceAccount. This is required to support IRSA (IAM Roles for Service Accounts) for users who have not yet migrated to EKS Pod Identity (or cannot migrate due to Fargate restrictions).

Environment

• Chart Version: 2.1.0 / 2.1.1
• Kubernetes Version: (Any)

Additional context
This regression forces users to use sidecar patching or Terraform to inject the IRSA role ARN, breaking standard GitOps workflows where the chart is expected to manage the ServiceAccount configuration.

[sdumser]

Update:
I also discovered that serviceAccount.create: false appears to be ignored in this version. The ServiceAccount is generated regardless of this setting (likely tied only to rbac.install).

This exacerbates the issue for GitOps users, as we cannot cleanly disable the broken ServiceAccount resource to replace it with a patched one; we are forced to apply a duplicate resource and rely on merge behavior.

[simonmarty]

In version 1.x, the template included a block to render {{ .Values.serviceAccount.annotations }}.

Are you positive about this? I'm looking through the git history for that rbac.yaml file here and it seems like it never had that block (same with daemonset.yaml).

Please lmk if I missed something.

[sdumser]

Thanks for checking the history, Simon. I apologize, I must have conflated the v1 chart with a custom fork or the Terraform module behavior we used previously. You are right that the git history doesn't show that block.

History aside, the blocker remains:
We rely on IRSA (IAM Roles for Service Accounts) for the Provider. The current templates/rbac.yaml hardcodes the metadata, so there is no way to inject eks.amazonaws.com/role-arn via values.

Additionally, serviceAccount.create: false appears to be ignored in this template, so I can't easily disable it to bring my own ServiceAccount without getting 'Duplicate Resource' warnings from ArgoCD.

Is there a recommended way in v2 to attach annotations to this ServiceAccount, or should we treat this as a feature request?

[simonmarty]

I pulled them in as feature requests. We'd be happy to review PRs if you already know the idiomatic way to do this. There might be a way to do this without modifying/forking the helm chart, but I don't know it off the top of my head.