Allow other hosts for AWS_CONTAINER_CREDENTIALS_FULL_URI

[jonathan-conder-sm]

Is your feature request related to a problem? Please describe.
I'm trying to use https://github.com/awslabs/amazon-ecs-local-container-endpoints with kubernetes. Related: awslabs/amazon-ecs-local-container-endpoints#48.

If I create a kubernetes service for one or more ECS local endpoints containers and tell my other containers about it using AWS_CONTAINER_CREDENTIALS_FULL_URI=http://name-of-service/creds, I get this error.

An alternative approach would be to use iptables to forward packets from the magic address (169.254.170.2) to the service. But I don't want to have to run iptables manually on every node. Also kubernetes won't let me assign a link-local address to a pod or service.

Another way would be to run the ECS container in the same pod as each of my other containers, and point them to it using AWS_CONTAINER_CREDENTIALS_FULL_URI=http://localhost/creds. I also don't like that approach because it requires each node to have AWS credentials stored on it. Also some of the pods run using custom resource definitions that aren't compatible with the ECS local endpoints container.

Describe the solution you'd like
I'd like a way to extend botocore.utils.ContainerMetadataFetcher._ALLOWED_HOSTS without monkey patching it.

One option would be to add another static entry, e.g. 'ecs-local-endpoints' to match the name of the service in the example compose file.

Another option would be to expose an API to customize the allowed hosts.

For me the first option would be better, because I won't have to modify code that already works on ECS. But I guess there are good reasons for limiting the allowed hosts by default.

[stobrien89]

Hi @jonathan-conder-sm,

Thanks for reaching out! I'm not sure if this is a change we'd be able to make, but I'll definitely check with the team to get their thoughts.

[stobrien89]

Hi @jonathan-conder-sm,

I reviewed this with the team today and it looks like we won't be able to extend or allow users to change the allowed hosts due to a org-wide security policy we have in place. Wish we could be of more help!

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[jonathan-conder-sm]

ok thanks anyway

[zamlz]

@stobrien89 I think this is a pretty frustrating limitation.
Specifically, when we are using docker containers to talk to the greengrass token exchange service. We are forced to put these containers into host networking mode which is less than ideal when it comes to security. These containers themselves are deployed with greengrass.

Containers that are not running in host networking mode can still talk to ports on the host system by adding extra hosts to the container that point to host-gateway which is something that docker service understands. Now if I have a service running on my host machine, I don't need to put my container in host networking, but instead I can simply talk to it via host-gateway:1234. The container is still fundamentally on the docker network bridge instead of being in host networking and we still keep some level of network isolation (that is my understanding).

All I really want to do is add host-gateway to this list.