使用 Google Cloud SQL 数据库时，私有 IP + SSL 或云代理 sidecar 之间有区别吗？

Question

在尝试评估如何从 Google Kubernetes Engine pod 连接到 Cloud SQL 数据库时，有几种方法可以做到这一点。一种是使用sidecar云代理。另一种方法是使用私有 IP 并在两者之间使用 SSL 连接。两者都有明确的案例吗？或者它们都提供相同的功能？有没有一种被认为是“最佳实践”？

Cloud SQL 代理边车

该云SQL代理三轮建立一个TCP连接到被谷歌的基础设施托管的代理服务。然后，这会将您连接到 Google 网络上的云 SQL 实例。

优点

• 无需管理应用程序中的加密材料即可建立安全连接
• 连接到实例，您无需管理 DNS 记录或 IP 地址

缺点

• 您必须创建一个密钥来存储服务帐户密钥。
• 您必须在 pod 旁边管理一个 sidecar 实例，如果失败，您将无法再连接到您的数据库
• 由于您拥有代理层的层数而增加了延迟

私有IP + SSL

使用私有 IP并将实例连接到您的 VPC 允许您使用内部 IP 地址，该地址未公开路由，并将流量保持在您的 VPC 实例中。最重要的是，设置到您的数据库的仅SSL连接以确保点对点的流量安全。

优点

• 与数据库的低延迟连接，因为它是点对点连接
• 您管理服务之间的密钥
• 无需外部依赖项或系统即可在两者之间进行连接

缺点

• 您必须在连接内管理 SSL 证书
• 您必须验证集群中的 IP 和 DNS 记录设置是否正确

我错过了什么吗？这两个确实提供相同的东西吗？两者之间没有绝对明确的赢家，您可以选择最适合您风格的那个吗？

Answer 1

最佳实践是使用代理。从安全的角度来看，它们都是不错的选择，但我发现管理自己的 SSL 密钥的麻烦只是我不需要的麻烦。同样正如 John 在他的评论中提到的，如果您出于任何原因移动区域或更改 IP，您必须更改容器内容，而不仅仅是代理启动时的标志。您当然可以在容器上使用环境变量来缓解这种情况，但这是另一回事。

代理 IMO 上有一个轻微的安全优势，因为如果您的密钥被盗用，则代理连接生成的临时密钥比您自己生成的 SSL 密钥寿命更短的窗口（除非您在 API 中使用临时密钥调用） ）。因此，如果在您的应用程序中发现漏洞，并且密钥遭到破坏，那么任何人都可以对您的数据库进行恶意操作的窗口较小。但特别是如果您只在一个不太担心但仍然大于零的 VPC 上。