For a long time, I’ve had a setup with Keycloak as the IDM. But Keycloak is heavy. It’ll OOM with less than 2G of RAM and needs a database too. It also has features I don’t care for, like realms. As I’ve been slowly moving to self-host a few more things, including outside of my home, I want to have a way to centralise authentication for those services too. I want to keep the IDM for the home lab separate from my cloud things. I also want something that fits in tiny places and needs few resources so I don’t have to pay for more expensive VPSes that’ll effectively be doing very little.
I’ve long been pondering setting up an Ory stack, but it’s a lot of moving components and databases. Then I accidentally stumbled across Kanidm, an open source IDM written in Rust. It ticks the “fits in tiny places” and “needs few resources” boxes and has Oauth2 support, including OpenID Connect Discovery. It also ticks a lot of my security requirements, including full Passkeys support. But, that’s not all! They have read-only LDAP support, so your legacy systems can auth that way. They have a system to handle Unix accounts with a PAM module. You can also use Kani for SSH public key distribution. It’s got service accounts and each service account can have multiple tokens. Last but not least, they have RADIUS support, so you can use it to authenticate users or devices on the network. It’s honestly a little mind-boggling all the things they support.
Before you get started, keep in mind Kani is still geared towards more technical users. The administration is CLI-only, and the web UI for users is very limited but good enough for what it needs to do. Installation instructions are geared towards running it from containers, but you can build from AUR on Arch Linux or use the scripts in the repo to build Debian packages.
Installation and configuration
Read the book. It has everything you need. The repository also has some example configurations. I would suggest taking a look at insecure_server.toml and playing around with that locally a bit first. Or the quickstart if you’re running with containers.
Once you have the hang of how it all works, then move on to a proper production deployment.
Disable the anonymous user
In my case, I don’t have a need for LDAP or the PAM integration to provision Unix accounts. At least, not on my cloud services. In that case, you can disable the anonymous service account:
kanidm service-account validity expire-at anonymous 1970-01-01T00:00:00+00:00 --name idm_admin
TLS
Kani mandates TLS everywhere, even between it and your load balancer or proxy. They explain this decision in why TLS. Since that can make experimentation a bit complicated, there is kanidmd cert-generate.
Proxy or load balancer
If you’re running Kani behind a proxy or load balancer, you’ll want to set trust_x_forward_for in your server.toml to true. This ensures Kani can detect the client IP which affects things like rate limiting. Remember to configure the host running Kani to only accept connections to Kani from the proxy or load balancer.
Backups
Backup your database. It uses SQLite internally and has a backup feature to create a copy of the database for you. You can then have your backup tool pick up that copy and store it safely.
Conclusion
Kani is a very tiny but very powerful IDM. You don’t need a separate database or other things like a Redis instance. It has a lot of features and has a very well thought out way of doing everything, including its permission hierarchy.
Kani is about to reach a stable release, so now’s as good a time as any to try it out. It’ll take a bit getting used to, but once you’ve done the setup it works flawlessly.