Re: Support kerberos authentication for postgres_fdw

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peifeng Qiu <peifengq(at)vmware(dot)com>, "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-10 20:45:17
Message-ID: CABUevEzgvqtAWMSm+jx0peiDa2fbCO6Aoym1KO1aUng6cZcsxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 9, 2021 at 3:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peifeng Qiu <peifengq(at)vmware(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2021-07-10 22:00:27 Re: unnesting multirange data types
Previous Message Tomas Vondra 2021-07-10 18:47:49 Re: Add ZSON extension to /contrib/