> I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS.
> If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is.
Would you mind sharing your argumentation about this, both in the context of Keycloak and in general?
In my eyes, enabling TLS on whatever application you want to run directly is almost always a bad choice, because you now need to deal with its unique implementation, as well as any vulnerabilities that the implementation could have. For example, even if all of your services run Java, you might find that a Spring application, a Spring Boot application, a Quarkus and a Vert.X application all have different ways of enabling it:
Spring example: https://www.baeldung.com/spring-channel-security-https
Spring Boot example: https://www.baeldung.com/spring-boot-https-self-signed-certificate
Quarkus example: https://quarkus.io/guides/http-reference#ssl
Vert.X example: https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/examples/EventBusExamples.java#L106 (couldn't even find docs)
And that's before you have parts of your stack running Node, Python, .NET, Ruby, PHP, Go or whatever else you might have to deal with. You can basically forget about automatically provisioning ACME certificates through Let's Encrypt, as well as being able to (easily) have all of your certificates in one place (at least for whatever that node needs), for easier renewals. This is especially noticeable when you want to serve dozens of different sites/applications from the same node.
In contrast, when you have a web server as your point of ingress, that then acts as a transparent reverse proxy in front of your applications:
- it takes care of all of the certificates, in a common format, they're easy to renew or can be provisioned thanks to ACME
- it can take care of other concerns, like path rewriting, HTTP to HTTPS redirects, rate limiting, additional caching or headers
- your applications can talk to one another in the internal network through HTTP, whereas encryption there can be added transparently
- with containers, this might be an overlay network where the clustering/networking solution takes care of internal certificates and rotates them often
So, how is that a bad choice? Some reasonable arguments that I can come up with are:
- it's easier to screw things up and expose stuff directly (e.g. port mappings, instead of overlay networks)
- one could feasibly argue that sometimes the application itself might want to look at the certificates and do something with them (e.g. expiry alerts)
- one could also argue that reverse proxies won't necessarily be perfect and some software might not correctly deal with headers
Perhaps I'm missing something that's staring me in the face.