Closed
Description
Is your feature request related to a problem? Please describe
This currently does not work per @mrzarquon
Describe the behaviour you'd like
Support ECR, but, persist image pull secrets in the cluster and rotate them on a schedule.
expand me to see alternative 2
One way to do it: - support accepting the name of an existing kube secrets in our install, instead of username/password (this is because if we are rotating secrets on a schedule, everytime the user does a kots deploy it will use whatever static value they entered for a secret) - take either aws keys OR a service account name that has permission to ECR (this means the user can create a service account in kuberenetes that has permissions to access ECR and never have to expose a secret to us) - setup a task that refreshes that docker secret with a new password every 12 hours - this sounds complicated but to people who use ecr, this is exactly what they have to do every timeHere are 33 lines of python for doing the password refresh from @mrzarquon experiment: https://github.com/mrzarquon/ecr-registry-refresh/blob/main/main.py#L47-L83
This'll be used by image-builder-mk3 (to create repos for base and workspaceImagel, so that it can build and push images) and well as registry-facade (so that it can pull the built images).
Describe alternatives you've considered
- Provide native support to use ECR as a container registry and also allows the use of IAM Roles for Service Accounts (in pods). In other words, do not depend on a kubernetes secret referencing an image pull secret. It should work - for public and private ECR registries, too.
- Continue not supporting ECR
Additional context
#2657 (originally mentioned)
#12060 (where we learned ECR is not supported, but lacks an issue, this one)