Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Firewall #6

Open
christopherobin opened this issue Feb 14, 2017 · 4 comments
Open

Proposal: Firewall #6

christopherobin opened this issue Feb 14, 2017 · 4 comments

Comments

@christopherobin
Copy link
Contributor

christopherobin commented Feb 14, 2017

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.

@stelcheck
Copy link
Member

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.

@christopherobin
Copy link
Contributor Author

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.

@stelcheck
Copy link
Member

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.

@christopherobin
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants