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

Security on public network #2136

Closed
sheerun opened this issue Dec 22, 2016 · 3 comments
Closed

Security on public network #2136

sheerun opened this issue Dec 22, 2016 · 3 comments

Comments

@sheerun
Copy link
Contributor

sheerun commented Dec 22, 2016

Hey,

I decided to connect nomad clients and servers through public network.

As far as I see, by default Nomad doesn't allow for authorizing its api endpoint (that can only use TLS for encrypting traffic, but not authorizing, as anyone can easily access and issue commands on exposed https api endpoint with something like --insecure flag of curl).

I figured out I can put nomad's api behind nginx proxy with basic auth enabled to secure the communication, but I have concerns whether the same bypass isn't possible for rpc and gossip traffic. So here is the question I'd like to ask:

Is it secure to expose rpc (with tls enabled) and gossip (with encryption enabled) endpoints on public network? Is it possible for attacker to inject arbitrary command, just like with http endpoint?

And if now: How can we enforce at token/userame-password authorization for all ports nomad uses?

@sheerun
Copy link
Contributor Author

sheerun commented Dec 22, 2016

Also: it there's no authorization when using TLS encryption, what is the exact use case for it? It seems encrypting traffic with TLS is meaningless if anyone with access to network where TLS takes place, can retrieve any information by querying any api with --insecure flag.. What did I miss?

@dadgar
Copy link
Contributor

dadgar commented Jan 3, 2017

@sheerun As you have identified, encryption and authentication/authorization are separate issues. TLS is an important first step so that sensitive data being sent to servers/clients is not over plaintext on the network.

We plan to handle the authN/authZ problem for HTTP with ACLs similar to Consul. This is on the roadmap but does not exist currently.

As to exposing RPC/Serf port that is fine when using TLS since we do mutual authentication. Thus we are using the certificate to authenticate.

I am going to close this issue since we have #227 and #589 open to address these issues!

I hope I answered all your questions. If not please let me know 👍

@github-actions
Copy link

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants