我们在 pgbouncer 中使用身份验证文件模式。Pgbouncer 的身份验证部分非常混乱。如果有人能解答我的以下疑问,将会很有帮助。
Pgbouncer 连接是否在保镖端和数据库层进行了两次身份验证?
如果 Pgbouncer 使用与数据库相同的凭据,那么身份验证有什么用?
除了数据库凭据本身之外,是否可以使用一组不同的用户凭据进行 Pgbouncer 身份验证?
我们在 pgbouncer 中使用身份验证文件模式。Pgbouncer 的身份验证部分非常混乱。如果有人能解答我的以下疑问,将会很有帮助。
Pgbouncer 连接是否在保镖端和数据库层进行了两次身份验证?
如果 Pgbouncer 使用与数据库相同的凭据,那么身份验证有什么用?
除了数据库凭据本身之外,是否可以使用一组不同的用户凭据进行 Pgbouncer 身份验证?
这很令人困惑。由于 pgBouncer 充当客户端和数据库之间的代理,因此身份验证分两个阶段进行:
客户端必须通过 pgBouncer 进行身份验证
pgBouncer 必须通过数据库进行身份验证
这两个步骤理论上是独立的,但您通常希望使用数据库凭据向 pgBouncer 进行身份验证。这就是
auth_query
目的。另一方面,您通常在数据库计算机上安装 pgBouncer,然后您可以trust
在 pgBouncer 和数据库之间使用身份验证,除非您的安全要求非常高。也许我关于该主题的介绍性文章对您有用。
pgbouncer 的要点是,并不是每个 pgbouncer 的连接都会创建一个到数据库的新连接。或者至少,这是一个重点,也许不是唯一的一点。
到 pgbouncer 的传入连接可能会导致对数据库本身进行身份验证,或者它可能只使用已经经过身份验证的数据库的现有连接。因此,连接会验证 1 + 1/N 次,一次到 pgbouncer,一部分时间到数据库(如果它是该池中的第一个连接,或者它导致池增长,或者需要替换过期或臭鼬连接)。我猜
你的pgbouncer 开发人员可以安排它,以便它在 (N-1)/N 的时间内向池化器进行身份验证,并在 1/N 的时间内通道到数据库,但因为它仍然需要乒乓通过池化器,很难看出这有什么意义。替代方案会是什么样子?pgbouncer 第一次通过数据库进行身份验证,然后只将该连接共享给出现的任何人,而不进行检查?或者连接永远不会被重复使用,在这种情况下,您的池化器不会进行池化?或者是其他东西?
是的,这是可能的(但我认为这并不常见)。但由于pgbouncer 中存在明显的错误,如果 SCRAM 尝试用于两组凭证,则不可能。