Skip to content

(helm) Service Account Support for K8s Resources in Helm Charts #778

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AlexB-mgtc opened this issue Mar 20, 2025 · 0 comments
Open

(helm) Service Account Support for K8s Resources in Helm Charts #778

AlexB-mgtc opened this issue Mar 20, 2025 · 0 comments

Comments

@AlexB-mgtc
Copy link

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe.
I need to use workload identity in managed Kubernetes services (GKE/EKS/AKS) to authenticate pods to managed cloud services like PostgreSQL, Redis, and object storage without embedding credentials.

Currently, the Helm chart doesn't support specifying custom service accounts for deployments and jobs, which prevents leveraging cloud provider IAM-based auth mechanisms.

Describe the solution you'd like
Add an optional serviceAccountName parameter to each component in the Helm chart (backend, frontend, yProvider) that would be applied to all relevant Kubernetes resources.

The parameter should be set at the component level and propagate to all resources created for that component (deployments, jobs, etc.).

This allows us to attach IAM roles to service accounts and use workload identity federation without embedding credentials in Kubernetes secrets.

Discovery, Documentation, Adoption, Migration Strategy
Users would configure the service account in their values.yaml file:

backend:
  serviceAccountName: backend-sa  # Custom service account for accessing managed database

frontend:
  serviceAccountName: frontend-sa  # Custom service account for accessing storage

yProvider:
  serviceAccountName: yprovider-sa  # Custom service account for collaboration

For users who don't specify a service account name, nothing changes (backwards compatible). For users who do, they would first create the service accounts in Kubernetes, then attach appropriate IAM roles based on their cloud provider's configuration.

Do you want to work on it through a Pull Request?
Yes, I can implement this feature. I've already created a draft implementation locally by adding the serviceAccountName parameter to the deployment and job templates and updating the values.yaml with proper documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

1 participant