IMHO, Kruise should not care about cloud providers. It just works on pure Kubernetes API.

The workaround is to have a kubernetes docker secret with the token and then keep on renewing it

I think EKS should the ability to manage and renew the secret for its users.

I think EKS should the ability to manage and renew the secret for its users.

Workloads on EKS does not need secrets by default, they just work as long as the nodes have proper IAM policies. EKS already takes care of the same i.e. whenever we have a docker image (like 111111111111.dkr.ecr.ap-southeast-2.amazonaws.com/traefik:v2.5.3), nodes can pull the docker image without worrying about the repository/registry authentication. My idea was to use the same/similar logic in Kruise too, it is just a good customer experience IMHO.

As I said earlier, I already have created a workaround which is to populate and renew the secret at regular intervals.

nodes can pull the docker image without worrying about the repository/registry authentication

I'm not sure how it works... Maybe they have modified the code of EKS kubelet, which can pull images from ECR with IAM Roles configured somewhere. Does it have some documentations of this?

Hi all. Is there something that I can do to help push this along?

Hi all. Is there something that I can do to help push this along?

Can you help us identify how EKS inject tokens into the pod? For example , can you check created pod yaml and check if pull secrets are injected by some webhook automatically.

@furykerry I can definitely help with that!

The native way that EKS supports pod identity is with a feature that they call IAM roles for service accounts. The way this works is that you add an annotation to a kind: ServiceAccount, then use that kind: ServiceAccount on the pod spec.

The EKS control plane then implements the webhook injection with this aws/amazon-eks-pod-identity project, which will inject a kind: Secret with the kind: ServiceAccount token, and will inject environment variables into the pod spec.

All AWS SDKs for every programming language looks to see if certain environment variables exist, and if they do, they will use the service account token and the identity of the pod to fetch AWS credentials which can then be used to call the AWS API.

Please let me know if any part of that doesn't make sense!

To anyone who comes across this topic, here's the terraform that I wrote to automate fetching an ECR token that OpenKruise can use for things like an ImagePullJob

https://gist.github.com/abatilo/d9234c85c420d08688fd353c591fef6d

aliyun also have similar technology:
https://help.aliyun.com/document_detail/159703.htm?spm=a2c4g.177224.0.0.50bb64f2XPn8yE#task-2456294