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
This is partly a suggestion about clarifying security model docs and partly a suggestion to improve the overall security of this integration if I'm understanding the current model correctly.
The diagram in the README is fantastic for showing how this integration works. It's not currently clearly stating the threat model.
As far as I can see, the haproxy-connect process is the one that is authenticated by an ACL to fetch certificates. Which way does the dataplane API connection work though? And from what I can see it talks to HAProxy dataplane as a client which means it doesn't expose an open interface that another process on the box can connect to and get access to certificates/keys? If I'm right that sounds good.
One potential issue I see though is that it uses a hard-coded dataplane user/pass for HAProxy:
This means that any other process on the box that can talk on that same unix socket and happens to know these credentials (it is open source after all) can completely reconfigure the proxy, for example to disable SPOE intention checking.
One possible simple solution would be to generate a strong crypto-random password for HAProxy on every startup so it's only in-memory in the consul-haproxy process and passed through to HAProxy. I guess the Config is written to disk so I'd suggest using the secure (hashed) password config to pass it through and hashing the random password in consul-haproxy. That way you can have high confidence that the only process able to configure the proxy is same consul-haproxy process that stated it.
The text was updated successfully, but these errors were encountered:
banks
changed the title
Documenting the threat model
Documenting the threat model/improving inter-process security.
Mar 3, 2020
This is partly a suggestion about clarifying security model docs and partly a suggestion to improve the overall security of this integration if I'm understanding the current model correctly.
The diagram in the README is fantastic for showing how this integration works. It's not currently clearly stating the threat model.
As far as I can see, the haproxy-connect process is the one that is authenticated by an ACL to fetch certificates. Which way does the dataplane API connection work though? And from what I can see it talks to HAProxy dataplane as a client which means it doesn't expose an open interface that another process on the box can connect to and get access to certificates/keys? If I'm right that sounds good.
One potential issue I see though is that it uses a hard-coded dataplane user/pass for HAProxy:
haproxy-consul-connect/haproxy/config.go
Lines 16 to 17 in 556c75e
This means that any other process on the box that can talk on that same unix socket and happens to know these credentials (it is open source after all) can completely reconfigure the proxy, for example to disable SPOE intention checking.
One possible simple solution would be to generate a strong crypto-random password for HAProxy on every startup so it's only in-memory in the consul-haproxy process and passed through to HAProxy. I guess the Config is written to disk so I'd suggest using the secure (hashed) password config to pass it through and hashing the random password in consul-haproxy. That way you can have high confidence that the only process able to configure the proxy is same consul-haproxy process that stated it.
The text was updated successfully, but these errors were encountered: