Open jimmyraywv opened 2 years ago
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. The idea is for the users to define a service account with the required IAM role that can pull the image from erc, and to set it as the scanner job service account (https://github.com/openclarity/kubeclarity/blob/main/charts/kubeclarity/templates/scanner-template-configmap.yaml#L19)?
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 https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html
on Kubeclarity https://medium.com/@samuelbagattin/aws-iam-authentication-for-pods-in-eks-irsa-with-examples-5d8fa16aafba is closet example what needs to be done (igonre the mutating webhook part)
User/(helm chart) need to create service account like this
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: "arn:aws:iam::ACCOUNT_ID:role/my-pod-role"
name: my-serviceaccount
namespace: default
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, Just wondering if there is any news on this? Thanks
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.