Thread: Support kerberos authentication for postgres_fdw
Hi hackers,
I'd like to add kerberos authentication support for postgres_fdw by adding two
options to user mapping: krb_client_keyfile and gssencmode.
In the backend we have krb_server_keyfile option to specify a keytab file to
be used by postgres server, krb_client_keyfile is doing mostly the same thing.
This allows postgres_fdw(backend process) to authenticate on behalf of a
logged in user who is querying the foreign table. The credential is kept in
the backend process memory instead of local file to prevent abuse by users
on the same host.
Because backend process is accessing the filesystem of the server host, this
option should only be manipulated by super user. Otherwise, normal user may
steal the identity or probe the server filesystem. This principal is the same to
sslcert and sslkey options in user mapping.
Thoughts?
Best regards,
Peifeng
Peifeng
Attachment
On Fri, Jul 09, 2021 at 10:13:20AM +0000, Peifeng Qiu wrote: > I'd like to add kerberos authentication support for postgres_fdw by adding two > options to user mapping: krb_client_keyfile and gssencmode. You may want to register this patch into the next commit fest, to get it reviewed for a potential integration in 15: https://commitfest.postgresql.org/34/ -- Michael
Attachment
Sorry I have sent a duplicate email. I will first continue discussion
in the other thread and then submit it after we have a conclusion.
Thanks.
Peifeng
Hi all.
I've come up with a proof-of-concept patch using the delegation/proxy approach.
Let's say we have two DB, one for FDW and one for the real server. When client
connects to FDW server using kerberos authentication, we can obtain a "proxy"
credential and store it in the global variable "MyProcPort->gss->proxy". This can
be then passed to gssapi calls during libpq kerberos setup when the foreign table
is queried.
This will mitigate the need for keytab file on FDW server. We will also have to
relax the password requirement for user mapping.
The big problem here is how to pass proxy credential from backend to libpq-fe
safely. Because libpq called in postgres_fdw is compiled as frontend binary, we'd
better not include any backend related stuff in libpq-fe.
In this patch I use a very ugly hack to work around this. First take pointer address
of the variable MyProcPort->gss->proxy, convert it to hex string, and then pass
it as libpq option "gss_proxy_cred". Any idea about how to do this in a more
elegant way?
Best regards,
Peifeng