Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2022-02-28 11:26:06 +0100, Peter Eisentraut wrote: > > We already have a variety of authentication mechanisms that support central > > management: LDAP, PAM, Kerberos, Radius. > > LDAP, PAM and Radius all require cleartext passwords, so aren't a great > solution based on the concerns voiced in this thread. IME Kerberos is > operationally too complicated to really be used, unless it's already part of > the operating environment.
... which is very, very, very often is, wrt Kerberos. > > What other mechanisms are people thinking about implementing using these > > hooks? > > The cases I've heard about are about centralizing auth across multiple cloud > services. Including secret management in some form. E.g. allowing an > application to auth to postgres, redis and having the secret provided by > infrastructure, rather than having to hardcode it in config or such. This sounds a lot like OAUTH or similar, which might be useful to consider adding if it can be done reasonably. > I can't see application developers configuring kerberos and I don't think > LDAP, PAM, Radius are a great answer either, due to the plaintext requirement > alone? LDAP is pretty clearly dying technology, PAM is fragile complicated C > stuff that's not portable across OSs. Radius is probably the most realistic, > but at least as implemented doesn't seem flexible enough (e.g. no access to > group memberships etc). Great thing about Kerberos is that, in general, application developers don't really need to do much to configure it. > Nor does baking stuff like that in seem realistic to me, it'll presumably be > too cloud provider specific. I don't quite buy an argument that hinges on the idea of centralized auth across multiple cloud services, as suggested above, while also being too cloud provider specific to be something that could be baked in, as said here. Maybe I'm misunderstanding. Also a bit concerned that adding hooks on presumptions about what some cloud provider needs isn't a good plan. In general though, I'm certainly more supportive of the idea of adding support for authentication mechanisms that are standardized and work across multiple cloud providers and services in general, than about adding things which are specific to one provider. I don't particularly care for the idea of adding hooks and then having cloud providers go off and develop their own proprietary authentication system that aren't standardized and which don't have public review, which seems like it's the use-case for adding them. I'm not dead-set against it, but it just doesn't strike me as a good area to add hooks for folks to use. Better would be baked in code that follows a well defined and reviewed RFC that anyone can look at and make sure follows the standard. Thanks, Stephen
signature.asc
Description: PGP signature