[Security] Allow blocking Write endpoints on Agent using Network Addresses

[pierresouchay]

Many endpoints in Consul allow write access on the API from all ports binded.

I propose to protect all APIs having a write access using network addresses: it would allow systems to block all Write calls easily.

Example for configuration added:

• allow_write_http_from: [ '127.0.0.0/8', '192.168.3.0/24']

This would allow performing HTTP API calls on endpoints performing write ONLY from any caller being on localhost or for instance 192.168.3.15.

We have this use-case where we want to use HTTP API calls from localhost for instance, but not from elsewhere. If HashiCorp is interested, we can provide a PR with implementation.

This is not the same use-case as ACL and would help having more robust Consul deployments in a company very easily.

[pierresouchay]

@pearkes we had a security issue related to that recently on a public server missing some iptables, would really be a big improvement to enhance security for many shops using Consul, and implementation is ready ;)

[vaLski]

The request totally make sense and cover real world scenario which @pierresouchay mentioned. I can also recall cases from my experience where iptables was considered critical but was down/disabled on host(s) thus exposing sensitive services.

Security is all about layers and this particular PR is adding layer that is both useful and cover real world case.

[pierresouchay]

@banks @mkeeler would you consider this as it allows simply enforcing security while not altering current behavior?

We are running this for a few weeks without any issue on our 10 clusters, and it really enforce security globally

[banks]

I can see the argument for an extra layer of defence. A small part of me is a little wary of implementing a feature that (arguably) is the responisibility of a firewall, just in case you misconfiguered your firewall.

I agree security is about layers for sure but on the other hand the logical conclusion of that is that every application should embed their own firewall/VPN/TLS/AuthZ just in case the layer above was misconfigured which is obviously not a sensible position. I'm not at all saying this proposal is ridiculous but just that it's a grey area.

I think the one thing that makes this more than just something you can do with a firewall is the fact that it's only for API endpoints that make changes. I'm interested @pierresouchay what your rationale is for that? In many setups if you accidentally listen on the wrong IP with no firewall just leaking read-access to all your stuff is pretty bad already, why only protect write APIs? (I can think of some reasons but it's useful to hear your rationale/use-cases too).

[pierresouchay]

@banks As you might know, we had an issue with a endpoint recently on our datacenters. It allowed us to completely block the bug without disrupting our service. Many of our administration scripts rely on being able to query agent remotely, so by enabling this, we allow other agents to query agent, but block them to change anything even when ACLs are misconfigured for instance or not working as suspected.

Some people might also not use any firewall on their infrastructure, and since ACLs tokens might be identical across agents, having this level of protection ensures that no one is able to leave all agents by simply taking control of one Agent and sending /v1/agent/leave on all agents of the cluster (for instance).

potables is enough to protect per IP, but having a simple way to block all side effects on the agents looks like a good addition (for instance, to not allow applications running on the machine to perform changes on the local agent by exposing them a specific network - which is blocked)

[banks]

Thanks. I think that is a reasonable rationale.

I'm thinking about how is best to document the options here to guide people to exposing the minimum necessary though - ideally if they don't actually need read access to agent APIs then they wouldn't listen on a public interface at all.

This is still a potentially useful even for the localhost-only HTTP listener though as it can be used to further lock down any write from application or malicious processes on the local machine too. We must be careful how to word that defensive approach though since a process on the same machine may depending on other security measures, be able to "write" by modifying the config on disk and restarting, or by reading ACL tokens and encryption keys from disk and pretending to be the agent and sending whatever packets it wants etc.

Overall, I think this seems like a good addition. We will think about how to pitch the documentation/warnings etc.

[pierresouchay]

@banks do you still considers this for 1.4.1?

Kind Regards

[banks]

Yep. Hopefully in the next week or two we'll start burning down the PRs in that milestone and getting them merged.

…

On Fri, Nov 30, 2018 at 12:05 AM Pierre Souchay ***@***.***> wrote: @banks <https://github.com/banks> do you still considers this for 1.4.1? Kind Regards — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4712 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHYU-RTVup9HX0doQV_aChEVhsaAQd4ks5u0HYygaJpZM4W6BKT> .

[mkeeler]

Closing as the fix was merged.