Feat: external LDAP as a source of truth #915
Comments
|
We had this question a few times by now. I don't have any single use case for LDAP and as long as not someone else provides a PR with a complete integration, or an external company requests this as a paid feature, it will not be implemented. If you need LDAP support, take a look at kanidm. |
|
"I don't have any single use case for LDAP" S3 policies KanIDM sadly hasn't been able to meet my needs. I will continue to recommend LLDAP with Authelia, but I hope this project will eventually come around when you get a good PR. It's really nice, and I hope it can compete with Authelia eventually. |
Running self-hosted Garage, which does not support LDAP and AWS policies.
Usually not using Postgres anymore, but if so, instances are usually set up via K8s operators which generate all creds as K8s secrets which can be accessed from all necessary deployments without me needing to touch them.
Is done on our side via a centralized, self-written cloud service already, which directly talks to the mail server and manages credentials automatically.
Kind of have that when taking a look at Rauthys Roles / Groups
Rauthy will eventually get its own PAM module which will probably even take care of hardware based FIDO 2 Keys in the console. The module itself is already working, but very experimental, and does not use FIDO2 keys yet. So yeah, I have no real need for LDAP.
Thanks, but it's not my goal to compete with anyone. Rauthy is a product out the need for a proper, internal solution and everything that existed back then (including Authelia) didn't really work out. I just don't see any advantage in having LDAP right now. It would be an additional attack vector, use more resources, is something else you need to manage. But if someone provides an integration at some point (which I doubt, because it would be a huge amount of work), I would of course happily merge it. |
Is it possible to explain a bit more about your workflow for new user and how you manage your self hosted mail server with your own domain onh your single source of truth user database, rauthy? Edit: Do you have mail aliases enabled on your mailserver? Where are these stored? Using custom attributes in rauthy to still have a real single source of truth? How will this be pushed/pulled to the mailserver? |
Rauthy is the single source of truth for all auth and user related values, not for every existing config value overall. Values that are needed in multiple places or just make sense to save together with a user are stored as custom attributes and managed by Rauthy. However, some data is managed in other places, when it's only really necessary over there. For instance in case of Postgres creds, they are auto-generated inside K8s as secrets and never leave the cluster. Whenever another application needs them, they are injected into the pods by referencing the original secret, so they only exist in one place and never leave it. Since Rauthy Depending on your mail server, you could also just manage them automatically via SCIM dire 8000 ctly. We just want to have some custom logic and a specific mailbox / address naming and additional things, so that it's easier to do this in the other application than to connect the mail server directly. You could use Rauthy as a single source of truth for most of the data via custom attributes. I just think it's better and easier to keep some stuff in even more locked down, not even publicly available locations (like e.g. K8s secrets with private K8s API), if you don't need them anywhere else. These days, I very much always follow the KISS principle. |
IMHO different usage. 1st one belongs to a service/environment, 2nd belongs to a human/user account.
For example birthday is also stored to a user directory (regardless if it's LDAP or rauthy) even if it is used rarely.
Also the 2nd mail address belongs to a user!?
What's the name of this cloud app, how to install? I'm not aware of a mail server right now, that supports SCIM |
Yes, everything service / env related lives only inside K8s on our side to keep it simple and the attack surface lower.
True, that's where SCIM comes in handy. Whenever a value is updated on Rauthy's side, the update will be propagated to downstream clients.
Yes, but this is dynamically managed and after they expire, they are blacklisted for 1 year to never have any overlaps, even though the addr has quite a lot of randomness.
You can't. It's an internal application written from scratch, because of the lack of options out there. Usually, people always refer to Nextcloud, but I have lots of issues with it for different reasons, which is why it has been created from the ground up.
Don't know if any support it out of the box, but I think that e.g. |
|
I certainly appreciate your enthusiasm and vision. I do however disagree with a K8s solution being simple or having a small attack surface. LDAP would still be my preference. I'm rather fond of both Nomad and Podman Quadlets, so a solution demanding K8s is a non-starter for my auth needs. I can completely understand if external sources of truth require a lot of work, and it's not where you'd want to take the project. The PAM module sounds very interesting. That would alleviate a lot of my concerns. |
Well, that is of course only true, if you have it running properly anyway already. Just running K8s to have a distributed storage for configs and secrets would be absolutely insane. It's the easiest and most straight forward in our case, since every single workload runs inside k8s, while its API is private and has multiple layers of protection. Quadlets are very nice, but I like to treat all my servers as being ephemeral. I want to be able to shut one down or maybe even exchange it as a whole for whatever reason and don't worry about prod at all.
Yeah it basically works fine with user + password, but I need to find some additional time to integrate Yubikeys / Webauthn into it and make it fully work. Once that is done, I will push it as a separate project. It cannot be added to the Rauthy repo directly because of licensing issues with some dependencies. |
That's what immutability is all about. CoreOS is alive and well as Fedora / Redhat CoresOS, and there's Nix, for people who are into learning new obscure languages for system management. My point is that Kubernetes is not the only way to achieve this, that's a fallacy being imposed on us all right now. That being said, I use Kubernetes, I just don't wish for projects to require it in the future. There will always be a minority opposed to it, and they are working hard on building new ways to work without it. The underpinnings are now in place, all that needs to happen is for either Fleet to be resurrected, or a new project to come in and replace it, or maybe Nomad gets adapted. Who knows, but choice is good, and Kubernetes is too resource heavy to go unchallenged forever.
If you promoted this front and center, it would prevent dummies like me from interrupting your work :) |
|
Right now, today, with no special knowledge or unproven techniques, I can build a Terraform / Ignition / Ansible / Fedora CoreOS / Nomad solution that is easier to access & comprehend for developers, and is lighter weight, than Kubernetes. That part is a fact. The biggest challenge has been convincing people Nomad is a living, advancing, solution ("It's AWS ECS for everyone" <-- my latest pitch to stakeholders). Nothing technical. I'm convinced that the first API based solution that embraces Podman Quadlets is going to become the next contender; be that Nomad, Fleet, or something else new. Kubernetes has inertia, and it's de-facto. My concern is the Titanic conjecture; where people begin believing it's unsinkable, and building solutions with that fallacy. That is not guaranteed. |
I never said that, of course it's not. I cannot think of any task that can only be solved in one specific way in this regard.
And again, never said that. Rauthy does not require it at all. You can run it anywhere you like.
I fully agree on that one.
Yeah I did not on purpose, because I don't want to make promises I cannot hold in the end. And, if I publish this, I want it to be working nicely without much trouble. Username + Password is straight forward and no big deal, but I want Webauthn in the terminal, preferrably even with devices that do the authentication via QR code, even though we only use Hardware Passkeys exclusively. Because I don't know yet how nicely this will work, I have not promoted this in any way yet. Generic PAM modules for OIDC / oauth logins exist already, so there is no need to reinvent the wheel, as long as it's not doing anything special.
I looked at a stack like this in the past as well, but it was not fully meeting my needs. In fact, I would really like ditching K8s for something lighter weight. I use |
It would be nice if Rauthy supported external sources of truth, such as LDAP. LDAP is not great at being an authentication protocol, but is excellent for a centralized authentication database. LDAP + OIDC is the ideal combination.
The text was updated successfully, but these errors were encountered: