Use Dynamic host.docker.internal Hostname Instead of Fixed IP Address

[mowoe]

As described in the README, the current setup relies on the host system using the default 172.17.0.1/16 prefix for its docker v4 network.

This however may not always be the case. Instead of a hard IP address, we can let docker handle the resolution to the host IP address with host.docker.internal. However, this means that the asterisk has to bind to all interfaces, since it has no knowledge of the host docker interface.
This means potentially exposing asterisk to the internet, which is a tradeoff I'm not 100% sure about, so I'm happy to get your input.
Additionally, this would mean that the config variable ASTERISK_AMI_ADDR has a different meaning in the two containers which is also sub-optimal.

Let me know what you think!

[mowoe]

CI fails because PR builds don't have access to repo secrets, just fyi.

[olell]

That's pretty cool, first of all thank you very much!

What do you think about resolving host.docker.internal in the entry point to only bind to this address with the AMI (or am
I wrong about the address it will resolve to)?

[mowoe]

Unfortunately, because the asterisk container is in network_mode: host, its DNS queries won't be resolved by the docker DNS server but the one in resolv.conf on your host, so it won't be able to get an IP address from that :(

[olell]

Just fyi, I am not really sure about the security implications of the AMI exposed to the internet. With secure credentials this would probably be fine, but I would prefer a security-by-default way in this case. With no AMI credentials (or default values) set this would be a huge security risk.

I haven't looked much into it, but don't you think there would be a way to tell the asterisk server whats the docker bridge IP?

[mowoe]

Just fyi, I am not really sure about the security implications of the AMI exposed to the internet. With secure credentials this would probably be fine, but I would prefer a security-by-default way in this case. With no AMI credentials (or default values) set this would be a huge security risk.

I agree!

The only way i could think of to somehow inject the bridge IP in the container would be via some ugly scripting logic, but i don't think thats the way to go...

[olell]

Totally, my initial idea was to simply add some firewall rules to the container which at least limits access to this port from non-rfc1918 addresses, which would reduce the risk. I wonder if @hirnpfirsich has any idea on this?