Lock Down Keycloak Admin Portal

[Tony Wu]

Hi,

Looking to standup a Keycloak cluster in AWS, current infrastructure consists of an external load balancer, a bunch of Keycloak containers, and an RDS in the back. Since most of the users will be vendors and 3rd party affiliate, we would like to lock down the admin portal (/auth/admin, and probably also /auth/realms/master). I googled a bit and crawled through some documentation and came across three potentially solutions, at least from my still limited understand:

1. Put an Nginx instance in front of the Keycloak containers and do whitelisting there. Caveat is that this will be either an additional layer of proxy, or we'll have to use Nginx instead of AWS LB.

2. Configure rewrite condition in JBoss. However doesn't seem to be an option with containers (at least I couldn't find anything related to this in Keycloak container documentation).

Is there any other solution that we can consider?

Thanks,

Tony Wu

[dc...@prosentient.com.au]

I suppose it depends on what you mean by lockdown. If you’re using an AWS ALB for the external load balancer, then you could add an IP address check on the /auth/admin path.

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/32a5bad3-74f0-4898-8753-e3aa6500085cn%40googlegroups.com.

[jake cabrera]

What was the third potential solution?

We did something like David Cook mentioned and set up an IP address restriction on that path (and a few other paths as well) using the JBoss CLI, though I believe you can also just add it in your standalone.xml or something but that wasn't the route we took. 

An example of how to do that can be found here: https://github.com/keycloak/keycloak-documentation/blob/main/server_admin/topics/threat/admin.adoc

However, please be sure that Keycloak is getting the true IP of the client. We set up our containers in docker and had to set the environment variable PROXY_ADDRESS_FORWARDING: “true” as well as workaround the docker ingress SNAT masquerade to get the correct client IP to show up. I'm not sure if this will be an issue with AWS LBs because we didn't use that, so thorough testing would be advised.

Thank you,

Jake Cabrera

[Tony Wu]

Hi Jake,

Are you building your own entrypoint script if you are using JBoss CLI? I didn’t see anything on the docker documentation that allows this configuration.

Best,

Tony Wu

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/c5a178b6-427e-44bc-ade5-35d20f77ca7dn%40googlegroups.com.

[Tony Wu]

Hi David,

Good point, I’ll give that a try.

Best,

Tony Wu

[jake cabrera]

Hi Tony,

Custom entrypoint is an option but not necessary. As part of the standard Keycloak Docker entrypoint, there's actually a section where you can set up scripts to run at startup (both JBoss scripts and Bash). On the Docker Hub documentation for the Keycloak image, there is a section titled "Running custom scripts on startup" that details this process.

However, the way we did it was we simply connected to the JBoss CLI (in /opt/jboss/keycloak/bin/jboss-cli.sh in the Docker container) and run the commands after the server is fully up (we couldn't connect to the JBoss server until after Keycloak was fully ready). We then extended the image (we also have other customizations that require us to extend the image) and run our production Keycloak off of these extended images.

Thank you,

Jake Cabrera