Docs: TLS between load balancer and kanidm #2731
Conversation
| Ultimately, any option that maintains the confidentiality and integrity of the communication will | ||
| suffice. Some options include, but are not limited to: | ||
|
|
||
| - Generating a self-signed certificate |
There was a problem hiding this comment.
Can we recommend a generic process for accomplishing this? kanidmd cert-generate exists, but the help text says the following:
[...] These certificates should not be used in production, they are for testing and evaluation only!
It feels odd to recommend something that comes with such a strong warning. But maybe, given the context, the warning doesn't necessarily apply?
There was a problem hiding this comment.
The self-signed certificates generated by Kanidm aren't designed for any production use, so until that changes the help text is correct.
There was a problem hiding this comment.
@yaleman Thank you for the input. Can we point to some concrete technical attributes of kanidm's own self-signed certificates as justification for them being unsuitable for production? e.g., things that should be done differently?
If it's just a matter of kanidm's self-signed certs not being designed for that purpose, perhaps it would be worthwhile to evaluate whether they are actually fit for the designed use-case or not? And perhaps that can open the door to contributions that would allow for this use case to be entertained?
There was a problem hiding this comment.
They're designed (ref: build_cert) for test/dev purposes only with a 5 day expiry and some simple defaults.
There's a whole bunch more config that goes into a well-formed certificate, including location, hostnames, contact details etc. If someone wanted to make it easy to generate them then it might be entertained, but ... there's also SO many other software platforms that can do this, and duplicating production quality features for the sake of it is something we try to avoid.
There was a problem hiding this comment.
I appreciate the context!
If the certificate is never going to be publicly exposed (e.g., LB and kanidm are on the same host), presumably the "well-formed" characteristics that you mentioned (location, contact, etc.) aren't really relevant?
Of course, stuff like hostnames and expiry need to be right regardless. (edit: on second thought, do they though? does certificate pinning care about inconsistent hostnames or expired certificates?) And those other characteristics start to matter a lot more if the LB and kanidm aren't local anymore, right?
also SO many other software platforms that can do this [generate self-signed certificates?\
Aside from smallstep (which just seems like running your own CA), mkcert (also makes a local CA, but tries to abstract that away for you), or cfssl (still uses a local CA), do you have any other suggestions?
For the use case of securing localhost communications, maybe I'm trying to hard to find something that isn't necessary? Perhaps it shouldn't be more complicated than a couple trusty openssl commands?
There was a problem hiding this comment.
It depends on the threat model of your environment, like most security decisions. If folks are reading our docs to decide on how to generate a the cert between their app and a load balancer, simple openssl commands would do fine. 😄
There was a problem hiding this comment.
I wonder if we should just make a cert-helper for that specific use case?
There was a problem hiding this comment.
on second thought, do they though? does certificate pinning care about inconsistent hostnames or expired certificates
that's up to your load balancer configs.
@Firstyear we could do that, sure
There was a problem hiding this comment.
If only I was already planning to make a CA ....
tl;dr
Give users some options to consider for how they could implement TLS between a load balancer (LB) and kanidm.
Motivation
While the docs make it clear that kanidm must be accessed over HTTPS, they do not provide much information regarding how to accomplish this between a LB and kanidm; this is left as an exercise to the reader.
For users who have their LB and kanidm on the same host and simply wish to have their reverse proxy communicate with kanidm using HTTP over localhost, this requirement can be quite the pain point.
In lieu of providing a more seamless solution for users, I think it would be ideal to at least somewhat enumerate the options available to accomplish this.
Why is this in draft?
Because I'm not super confident with what I have written so far and would like some input from others so I can iterate.
Related
#1726 (comment)
#2403
Various discussions in the kanidm Gitter community.
❤️