Feature Request: Watch ServiceAccount Annotations for Changes #1019
Description
Is your feature request related to a problem? Please describe.
When I update a ServiceAccount's IAM role annotation (eks.amazonaws.com/role-arn) in EKS with IRSA, the existing Pods in Deployments and DaemonSets continue running with the old role ARN. This causes AWS API authorization failures because the role ARN is injected into Pods at creation time via environment variables and projected tokens. Currently, I have to manually restart all affected workloads after every ServiceAccount annotation change, which is error-prone and disrupts our CI/CD automation.
Describe the solution you'd like
I would like Reloader to watch ServiceAccount resources for annotation changes and automatically trigger rolling restarts of Deployments, StatefulSets, and DaemonSets that reference the modified ServiceAccount via spec.serviceAccountName. The feature would work similarly to how Reloader currently handles ConfigMaps and Secrets:
apiVersion: v1 kind: ServiceAccount metadata: name: my-app-sa annotations: reloader.stakater.com/match: "true" eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-new-role
When the ServiceAccount annotations change (particularly IRSA role ARNs), Reloader would automatically detect this and restart all Pods using that ServiceAccount, ensuring they pick up the new role credentials.
Describe alternatives you've considered
Manual rollout restarts - Adding kubectl rollout restart commands in our CI/CD pipeline after ServiceAccount updates, but this requires maintaining a mapping of which workloads use which ServiceAccounts and is prone to human error.
Additional context
This is particularly relevant for EKS environments using IRSA (IAM Roles for Service Accounts), where IAM roles are frequently rotated or updated as part of security best practices or when permissions need to change. The AWS pod identity webhook injects the role ARN as environment variables (AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE) at Pod creation time, so existing Pods never receive updates when the ServiceAccount annotation changes. Similar use cases might exist for other ServiceAccount annotation changes in different Kubernetes environments (GKE Workload Identity, Azure Workload Identity, etc.).