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
The current deployment we have is perfectly fine in a closed network, such as local infrastructure or a properly configured amazon VPC with security groups but is far too open for any infrastructure that exposes all the machines to the internet (ie. niftycloud?, bare-metal, etc...).
iptables
iptables is the obvious goto, at least to start with, the setup would lock any port but 80 below 20000 (? TBD) to be accessible only to a certain range of IPs defined in the inventory. We also might allow the user to define other ports than 80 to be open.
Only locking this range allows for users to potentially expose some containers without having to make changes to the inventory and using a higher port, obviously anything HTTP should go through Traefik.
Issues
iptables is a little rigid though, any changes to the configuration will need a reprovision of the cluster, which might be costly on large clusters.
The text was updated successfully, but these errors were encountered:
As mentioned during our discussions, this also ends up being rather inflexible when working with external customers hoping to access cluster(s) remotely.
Ideally, the iptables rules would be rather fixed, and through authentication become more open, I think.
Potentially once teleport is implemented one could use the forward flag to access ports behind the firewall, but yeah it's still problematic.
I guess #7 would allow us to have more relaxed rules, but some software such as elasticsearch or kibana do not have native authentication mechanisms and while we could route them through traefik, if we have a cluster issue where traefik is not starting for some reason then the user has now way to access monitoring/logs.
Arguably for anything HTTP/TCP can't we simply force route through Traefik?traefik/traefik#10 is not done, but there seems to be hints online that tcp proxy should work... as for HTTP, we should be able to IP filter/basic auth, which should be good enough.
Still no PR though is it might be some months away, unless we decide to submit a PR ourselves.
So for now I'd guess using the swarm expose + teleport forward or docker run (temp client container) for the rare situation where you need access to a TCP service in production should work
Description
The current deployment we have is perfectly fine in a closed network, such as local infrastructure or a properly configured amazon VPC with security groups but is far too open for any infrastructure that exposes all the machines to the internet (ie. niftycloud?, bare-metal, etc...).
iptables
iptables
is the obvious goto, at least to start with, the setup would lock any port but 80 below 20000 (? TBD) to be accessible only to a certain range of IPs defined in the inventory. We also might allow the user to define other ports than 80 to be open.Only locking this range allows for users to potentially expose some containers without having to make changes to the inventory and using a higher port, obviously anything HTTP should go through Traefik.
Issues
iptables
is a little rigid though, any changes to the configuration will need a reprovision of the cluster, which might be costly on large clusters.The text was updated successfully, but these errors were encountered: