Re: Support kerberos authentication for postgres_fdw - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Support kerberos authentication for postgres_fdw
Date
Msg-id CABUevEzgvqtAWMSm+jx0peiDa2fbCO6Aoym1KO1aUng6cZcsxQ@mail.gmail.com
Whole thread Raw
In response to Re: Support kerberos authentication for postgres_fdw  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Support kerberos authentication for postgres_fdw  (Peifeng Qiu <peifengq@vmware.com>)
List pgsql-hackers
On Fri, Jul 9, 2021 at 3:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peifeng Qiu <peifengq@vmware.com> writes:
> > I'd like to add kerberos authentication support for postgres_fdw by adding two
> > options to user mapping: krb_client_keyfile and gssencmode.
>
> 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.
>
> Is there some other way?

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.

At least at a quick glance this does not look like what this patch is
doing, sadly.

What does kerberos auth with a fixed key on the client (being the
postgres server in this auth step) actually help with?

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Add ZSON extension to /contrib/
Next
From: Alexander Korotkov
Date:
Subject: Re: unnesting multirange data types