[BUG?] Agent doesn't modify pods if they are created shortly after Pod Identity Association is created

[krzwiatrzyk-lgd]

I'm working on a Just In Time feature to create pod identity associations for a service account when needed.

In brief, the (non-working) process looks like this:

1. Create ServiceAccount
2. Create Pod Identity Association
3. Deploy Kubernetes Job using ServiceAccount.

Those steps are executed one after another, and due to some agent (eks-pod-identity-agent) behavior, it doesn't work correctly.

The agent has not properly mutated the pod created for the job (it didn't add the required environment variables). However, if the process waits a few seconds (5-10), the agent will properly mutate the pod, and it can start with proper access to the IAM role.

Working process:

1. Create ServiceAccount
2. Create Pod Identity Association
3. Wait 5 seconds
4. Deploy Kubernetes Job using ServiceAccount.

So, it seems the agent doesn't check if an association exists in the EKS API if it's unavailable in the agent cache.

Is that intended behavior? Can I somehow mitigate this?

[taraspos]

I've seen similar behaviour but I don't think eks-pod-identity-agent is responsible, but amazon-eks-pod-identity-webhook. See following issue:

• Webhook not injecting Env Vars or Volumes/VolumeMounts on initial deployment to a new cluster amazon-eks-pod-identity-webhook#174

[krzwiatrzyk-lgd]

Thanks! It seems that 4 days ago a fix has been merge, I will try to verify that if it helps and update this issue with result

[krzwiatrzyk-lgd]

I have no clue how to determine wether released fix doesn't work for me or is it not yet released :/ closing this issue as it is caused by referenced issue