aws
[EKS] [Addon]: Allow image/repository override for EKS managed add-ons (e.g., AWS Pod Identity Agent)
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request What do you want us to build?
Due to our enterprise security and network policies, our EKS clusters run with strict egress controls, and all container images must be sourced from approved internal registries. We also maintain hardened, scanned, and signed images to meet compliance requirements. Because of this setup, we must be able to customize the container images used by EKS managed add-ons.
Which service(s) is this request for? EKS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
The AWS EKS managed add-on for the AWS Pod Identity Agent currently allows changing only the imagePullPolicy. It does not expose settings to override the container image (repository and tag/digest). The upstream Helm chart already supports overriding the image repository and tag, so the capability exists in principle but is not surfaced by the managed add-on.
Without the ability to set the image repository and tag/digest, we cannot deploy the add-on in our restricted environments. This blocks adoption of the AWS Pod Identity Agent and, more broadly, limits our ability to use other EKS managed add-ons under the same constraints.
Please enhance the AWS EKS managed add-on for the AWS Pod Identity Agent to allow overriding:
- image repository
- image tag (and ideally digest)
- imagePullPolicy (already supported)
- imagePullSecrets (for private registries)
We also kindly request that this baseline functionality (image repository and tag/digest override, plus imagePullPolicy and imagePullSecrets) be standardized across all current and future EKS managed add-ons. Without it, we are unable to use these add-ons in production.
Are you currently working around this issue?
Deploying the upstream Helm chart directly works for us because it supports image overrides; however, we prefer the AWS managed add-on for its lifecycle management, compatibility assurances, and operational simplicity. CDK also integrated with this Addon and will not work without it (L2 Construct for ServiceAccounts)
Additional context
Our environments are private and tightly controlled (no direct public egress). We must pull only from approved internal registries and often mirror or rebuild vendor images for compliance. The upstream Helm charts already support these values; exposing them in the managed add-ons should be a relatively small change and would significantly improve enterprise adoption.
Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
Part of the value proposition of EKS addons is the version matrix and testing against K8s versions of our addons. If you replace the image we ship with, what value are you getting out of EKS addons vs just using a helm chart?
I completely understand your point, for most customers the default behavior makes perfect sense.
However, there are a few special cases with the EKS Pod Identity project:
- It does not provide a published Helm chart, only a repository you can clone.
- If you choose to deploy the raw manifests yourself, you lose the ability to use CDK features such as automatic ServiceAccount creation.
These are just examples, but they highlight why flexibility is important. In general, customers should always have the option to use their own image, whether for security, compliance, or other operational requirements.
I agree customers should always have the option to DIY images/manifests with EKS, we will never change that stance. But it just doesn't make sense to me with addons because that's a major part of the feature on its own.
To me this seems more a request to have a published helm chart for the pod identity agent
That makes sense and I agree that addons provide value precisely because they simplify things.
However, even with a published Helm chart, the challenge with CDK would still remain. The CDK logic around how the addon is deployed would also need to change to support this use case. (https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_eks.IdentityType.html#pod_identity)
Providing an option in the addon (similar to the one that already exists in the Helm chart) feels like the most flexible and customer-friendly approach. It doesn’t force anyone to use a custom image, but it enables those who need it! Whether for security, compliance, workflow reasons or CDK Limitations.
Since the Helm chart already supports this capability, aligning the addon with it seems like a natural next step.
As already mentioned, customers with isolated clusters (without outgoing Internet traffic) are currently unable to take advantage of EKS add-ons and their benefits. These customers are left out and have to invest more in operations and development to achieve the same goal.
