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

Documenting the threat model/improving inter-process security. #12

Open
banks opened this issue Mar 3, 2020 · 0 comments · Fixed by #47
Open

Documenting the threat model/improving inter-process security. #12

banks opened this issue Mar 3, 2020 · 0 comments · Fixed by #47
Assignees
Labels

Comments

@banks
Copy link

banks commented 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:

dataplaneUser = "haproxy"
dataplanePass = "pass"

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.

@banks banks changed the title Documenting the threat model Documenting the threat model/improving inter-process security. Mar 3, 2020
@amelhusic amelhusic self-assigned this May 6, 2020
@aiharos aiharos linked a pull request May 11, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants