google-cloud-platform - 使用 Google Cloud SQL 数据库时，私有(private) IP + SSL 或云代理 sidecar 之间有区别吗？

Question

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

Cloud SQL 代理边车

cloud sql proxy sidecar 与托管在 Google 基础架构上的代理服务建立 TCP 连接。然后，这会将您连接到 Google 网络上的云 SQL 实例。

优点

无需管理应用程序中的加密 Material 即可建立安全连接

连接到实例，您无需管理 DNS 记录或 IP 地址

缺点

您必须创建一个存储服务帐户 key 的 key 。

您必须在 pod 旁边管理一个 sidecar 实例，如果失败，您将无法再连接到数据库

由于代理层的层数增加了延迟

私有(private) IP + SSL

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

优点

与数据库的低延迟连接，因为它是点对点连接

您管理服务之间的 key

两个

之间无需连接外部依赖项或系统

缺点

您必须管理连接内的 SSL 证书

您必须验证集群中的 IP 和 DNS 记录设置是否正确

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

Answer 1

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

代理 IMO 有一个轻微的安全优势，因为如果您的 key 被泄露，代理连接生成的临时 key 的生命周期比您自己生成的 SSL key 的生命周期短(除非您在 API 中使用临时 key 调用)。因此，如果在您的应用程序中发现漏洞，并且 key 被泄露，那么任何人都可以对您的数据库进行恶意操作的窗口较小。但特别是如果您只使用一个不太值得关注但仍大于零的 VPC。