It should be possible to modify the default service account on EKS cluster creation
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
### Describe the feature
It would be very convenient if it was possible to patch or overwrite the default service accounts by using CDK. There could be an equivalent to `kubectl patch`, or you could be able to simply replace the default service account with a new one. This would allow all pods added to have certain IAM permissions by default.
This behavior should essentially be the same as the `--override-existing-serviceaccounts` used in `eksctl create iamserviceaccount`. If possible, something like a boolean `override-existing` flag added to the `cluster.addServiceAccount` function could be a concise way of handling this.
Another approach would be to add a function that can get service accounts from the service account from the cluster, i.e. `const devDefaultSA = cluster.getDefaultServiceAccount(namespace='dev')`. That way I could just call grants onto that default service account, i.e. `myS3Bucket.grantRead(devDefaultSA)`
### Use Case
I'd like it so that any pod created in my cluster is able to read from a specific S3 bucket. It would be very convenient for my use case if I didn't have to modify the manifest or helm chart to do this, given that I am currently able to just pull the chart from a repository.
### Proposed Solution
_No response_
### Other Information
_No response_
### Acknowledgements
- [ ] I may be able to implement this feature request
- [X] This feature might incur a breaking change
### CDK version used
2.20.0 (build 738ef49)
### Environment details (OS name and version, etc.)
macOS Monterey Version 12.1
Contributor guide
Research direction
Start by reviewing the EKS cluster.addServiceAccount API and the existing service-account behavior, then compare the requested options with eksctl's --override-existing-serviceaccounts flag. Define which API should support modifying the default account and how the breaking-change concern is handled. Done means pods can inherit the requested IAM permissions without changing their manifests or Helm chart.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes, typescript
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100