基于证书的 S3 身份验证

安全在 MinIO 中至关重要，与性能、简单性和弹性并列，成为至关重要的因素。

MinIO 在将数据存储到磁盘和通过网络传输时都会对其进行加密。MinIO 的最先进加密方案支持使用现代、行业标准加密算法（如 AES-256-GCM、ChaCha20-Poly1305 和 AES-CBC）进行细粒度的对象级加密。MinIO 与 S3 加密语义完全兼容，还扩展了 S3，包括支持非 AWS 密钥管理服务，如 Hashicorp Vault、Gemalto KeySecure 和 Google Secrets Manager。

鉴于 S3 的普遍性，几乎所有编排应用程序都使用它作为持久层。 这里一个关键问题是

它们的认证流程应该是什么样子，访问凭证应该如何管理？

由于这些系统由编排器（如 Kubernetes）自动化，通常没有人类用户使用特定于用户的登录凭证。S3 仅依赖于使用 S3 客户端和 S3 服务器之间共享的密钥（AccessKey | SecretKey）进行认证。然而，管理静态密钥是一场安全噩梦，而手动管理临时密钥则是一场组织噩梦。

因此，S3 协议包含一个扩展——安全令牌服务 (STS)——从各种不同的凭证类型请求临时访问 | 密钥对。对于人工认证，STS 支持 OpenID Connect (OIDC)。但 OIDC 具有交互式认证流程，不适合自动化服务。

因此，MinIO 实现了另一种 STS 认证类型：使用客户端证书进行认证，也称为 **AssumeRoleWithCertificate**。与其他 STS 认证类型类似，S3 客户端可以通过 X.509 / TLS 证书进行认证，请求临时 S3 访问凭证。

S3 客户端拥有由证书颁发机构 (CA) 颁发的 TLS 客户端证书，并访问 AssumeRoleWithCertificate API。S3 服务器在建立 HTTPS 连接时接收客户端证书，并验证其真实性——即验证它是否由受信任的 CA 颁发。

然后，S3 服务器使用证书通用名 (CN) 将证书映射到 S3 策略。例如，为 CN *my-demo-app* 颁发的证书将映射到 *my-demo-app* S3 策略。如果存在这样的策略，S3 服务器将生成与映射的 S3 策略关联的新临时访问 | 密钥对，并将密钥对发送给客户端。最后，S3 客户端可以使用接收到的临时凭证执行 S3 操作——如上传或下载数据。

这种认证工作流具有多种优势，尤其适用于自动化应用程序。

• 基于证书的认证需要 TLS 连接。S3 访问凭证不会通过不安全的网络连接泄露。
• 证书是证明互联网上服务身份的标准方式，因此在 SDK 和编程语言中得到广泛支持。
• 基于证书的认证是“离线”的，因为 CA 不需要在每次认证发生时都在线。这提高了整个系统的可用性 / 容错能力。
• 证书本身是临时的。它们会过期并变得无效。此外，可以根据需要请求新的证书。

特别是，Kubernetes 提供了用于向 Pod 请求和颁发证书的 证书 API。这使得为在 Kubernetes 上运行为 Pod 的应用程序配置证书变得非常容易。通过这种实现，应用程序可以使用其证书来验证其 S3 持久层对 MinIO 的身份。这种基于身份的认证在服务到服务认证方面减少了许多组织上的麻烦，并且 S3 客户端很容易采用和使用。

如果您想更详细地了解用于证书的 STS API 或具体的配置，请查看我们的 AssumeRoleWithCertificate 文档。