Re: Support kerberos authentication for postgres_fdw

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Peifeng Qiu <peifengq(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support kerberos authentication for postgres_fdw
Date: 2021-07-12 21:26:54
Message-ID: 20210712212654.GD20766@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Mon, Jul 12, 2021 at 5:43 AM Peifeng Qiu <peifengq(at)vmware(dot)com> wrote:
> > >As you note, this'd have to be restricted to superusers, which makes it
> > >seem like a pretty bad idea. We really don't want to be in a situation
> > >of pushing people to run day-to-day stuff as superuser. Yeah, having
> > >access to kerberos auth sounds good on the surface, but it seems like
> > >it would be a net loss in security because of that.
> >
> > I can imagine the use case would be a superuser creates the user
> > mapping and foreign table, then grants access of foreign table to
> > a normal user. This way the normal user can execute queries on the
> > foreign table but can't access sensitive information in user mapping.
> >
> > The main purpose of this patch is to provide a simple way to do
> > kerberos authentication with the least modification possible.
>
> But in this case, what dose Kerberos give over just using a password
> based solution? It adds complexity, but what's teh actual gain?

This is a bad idea.

> > >ISTM the right way to do this would be using Kerberos delegation. That
> > >is, the system would be set up so that the postgres service principal
> > >is trusted for kerberos delegation and it would then pass through the
> > >actual Kerberos authentication from the client.
> >
> > I agree this sounds like the ideal solution. If I understand it correctly,
> > this approach requires both postgres servers to use same kerberos
> > settings(kdc, realm, etc), and the FDW server can just "forward"
> > necessary information to authenticate on behalf of the same user.
> > I will spend some time to investigate it and reach out later.
>
> I don't actually know if they have to be in the same realm, I *think*
> kerberos delegations work across trusted realms, but I'm not sure
> about that.

This is a good idea, and yes, delegation works just fine across realms
if the environment is properly set up for cross-realm trust.

Kerberos delegation is absolutely the way to go here. I don't think we
should even be thinking of accepting something that requires users to
put a bunch of keytab files on the PG server to allow that server to
reach out to other servers...

I'd be happy to work with someone on an effort to support Kerberos
delegated credentials; it's been something that I've wanted to work on
for a long time.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-07-12 21:30:49 Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)?
Previous Message Tomas Vondra 2021-07-12 21:15:04 Re: [PATCH] Don't block HOT update by BRIN index