aws
It should be possible to modify the default service account on EKS cluster creation
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
@otaviomacedo, is the AWS team planning to address this issue in the near future? Currently, this limitation requires us to implement a custom workaround, whereas ideally, this could be resolved simply with a built-in flag in the CDK.
I believe features currently supported by the eksctl tool should be seamlessly available in aws-cdk without additional complexity. I reached out to AWS Premium Support, and they recommended creating a custom Lambda function to verify the existence of the service account and handle it accordingly.
