On Mon, Jul 12, 2021 at 5:43 AM Peifeng Qiu <peifengq@vmware.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?
> >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.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
