S3 的基于证书的身份验证

安全性在 MinIO 中是最重要的，并且在重要事物的万神殿中以性能、简单性和弹性位居首位。

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

鉴于 S3 无处不在，几乎每个编排的应用程序都将其用作持久层。这里的一个关键问题是：

他们的身份验证流程应该如何以及访问凭据应该如何管理？

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

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

因此，MinIO 实现了另一种 STS 身份验证类型：使用客户端证书 aka 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 访问凭据不能通过不安全的网络连接泄露。

• 证书是在 Internet 上证明服务身份的标准方式，因此得到 SDK 和编程语言的广泛支持。

• 基于证书的身份验证是“离线”的，因为 CA 不需要在身份验证发生时在线。这提高了整个系统的可用性/容错能力。

• 证书本身是暂时的。它们会过期并失效。此外，可以在需要时申请新证书。

特别是，Kubernetes 提供了一个证书 API，用于向 Pod 请求和颁发证书。这使得使用证书在 Kubernetes 上配置作为 pod 运行的应用程序变得非常容易。有了这个实现，应用程序可以使用他们的证书向 MinIO 作为他们的 S3 持久层进行身份验证。这种基于身份的身份验证在服务到服务身份验证方面减少了很多组织难题，并且非常容易被 S3 客户端采用和使用。

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