-
Notifications
You must be signed in to change notification settings - Fork 4
Add IRSA Support for Pod Access to ECR #662
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I see the issue is closed as completed but I dont see any mention about irsa in the readme |
This is kind of blocker to use with aws eks and ecr. |
Hi @jimmyraywv, thanks a lot for opening the request, and sorry for the long time it was stale. |
It needs change here as well https://github.com/openclarity/kubeclarity/blob/main/runtime_scan/pkg/scanner/creds/ecr.go#L32 to exchange IRSA token. |
Hi @shukla2009, thanks for the reference. I wanted to understand/confirm what is expected to be done from the user side to allow KubeClarity to access the token. If that's the only thing, we can create an EKS env with IRSA config and make the needed changes. |
on Aws enable IRSA on Kubeclarity User/(helm chart) need to create service account like this
Then scanner job must be created with the same service-account ( which mounts the IRSA token) ecr.go must exchange IRSA token to get credentials (reference is available in above example) |
@shukla2009, thanks for the info! We'll try that. By the way, any contribution is more than welcome :) If you managed to get it working already in KubeClarity, please feel free to create a PR :) |
@shukla2009, if you are interested of creating a pull request, we can assign this issue to you. If not, we can start working on it in a week from now. Thanks again! |
was there any progress since the above messages? I am using the default way of accessing ECR but I want to migrate to IRSA for security purposes |
Hi @giovannirco, @lgecse will lead this and update on progress. |
Hey Team, |
Is your feature request related to a problem? Please describe.
Currently the ECR support requires management of separate IAM credentials and kubernetes secrets. Using an IAM Roles for Service Accounts (IRSA) approach would allow the reuse of IAM policies, and remove the need to manage IAM users and Kubernetes secrets.
Describe the solution you'd like
Remove the use of static secrets and use IRSA instead. This approach is supported by Amazon EKS and non-EKS Kubernetes on AWS, with the Amazon EKS Pod Identity Webhook. The approach is described in this blog post.
Describe alternatives you've considered
I used kiam and kube2iam in the past, but both solutions required pod-level access to host-level instance metadata service (IMDS) to use the AWS EC2 host instance profile. Preventing the pods from accessing the AWS EC2 IMDS is considered a best practice, and prevents the pods from gaining access to permission meant for the host.
Additional context
The use of IRSA is considered a best practice when integrating Kubernetes pods to AWS IAM.
The text was updated successfully, but these errors were encountered: