You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Surely, but this is an extremely lightweight appliance. Why would you want to complicate the one instead of deploying multiple instances? When rubbing in a kubernetes environment (as it's planned, no?), I would generally prefer a micro services approach anyway.
It's also not just a concern of reading the host header. We would also need to have a whitelist to prevent us from being an open proxy.
Why would you want to complicate the one instead of deploying multiple instances?
Each instance run needs its own resources for base load as well as peak limits.
Going further: for multi-availability-zone scenarios, to lower interAZ networking costs you'd likely want to run it in each AZ.
I see this as a growing waste of resources that could be fixed if you handled multiple registries at once.
It's also not just a concern of reading the host header. We would also need to have a whitelist to prevent us from being an open proxy.
Yeah I would expect a configuration like: --accounts ecr-proxy-development.ecr-proxy.svc:123456789,ecr-proxy-production.ecr-proxy.svc:987654321 where you map specific hosts to specific ecr registries.
Currently
ecr-proxy
takes a single ECR repo to proxy via a command line argument.This means to access different ECR registries a user needs to run multiple instances of
ecr-proxy
.Instead, could you proxy to different accounts/registries based on e.g. a Host header?
The text was updated successfully, but these errors were encountered: