MinIO Operator 的安全令牌服务 (STS)

概述

STS 对 MinIO Operator 的优势包括：

• STS凭据允许应用程序访问 MinIO 租户中的对象，而无需在租户上为应用程序创建凭据。

• 允许应用程序使用 Kubernetes 原生认证机制访问 MinIO 租户中的对象。

  Service Accounts 或 Service Account Tokens 是 Kubernetes 的核心概念之一基于角色的访问控制 (RBAC) 认证在 Kubernetes 中。

• 为 MinIO Operator 实施 STS 允许您通过使用租户自定义资源定义（CRD）和 MinIO PolicyBinding CRD 来利用基础设施即代码原则和配置。

Kubernetes 中的 STS 授权工作原理 在 Kubernetes 中，STS（Security Token Service）授权机制通过以下流程实现身份验证与权限控制： 1. **身份提供方集成** - Kubernetes 集群配置 OIDC 身份提供方（如 AWS IAM、Azure AD） - Pod 通过 ServiceAccount 获取可投射令牌（Projected Token） 2.

应用程序可以使用一个AssumeRoleWithWebIdentity包含 a 的通话Kubernetes Service Account 的 JWT向 MinIO Operator 发送临时凭证请求。 当关联到 Pod 时，例如通过部署的.spec.spec.serviceAccountNamefield, Kubernetes 挂载一个JWT从已知位置（例如/var/run/secrets/kubernetes.io/serviceaccount/tokenPod 可以从该位置访问这些服务账户。

操作员检查请求的有效性，检索应用程序的策略，从租户处获取凭据，然后将凭据传回应用程序。 应用程序使用颁发的凭据与租户上的对象存储进行交互。

完整流程包括以下步骤：

1. 应用程序发送一个AssumeRoleWithWebidentity API请求到包含租户命名空间和要使用的服务账户的 MinIO Operator。

2. MinIO Operator 使用 Kubernetes API 来检查与 JSON Web Token (JWT) 关联的服务账户应用程序的请求是有效的。

3. Kubernetes API 返回其有效性检查的结果。

4. MinIO Operator 会检查策略绑定与应用程序匹配的。

5. PolicyBinding CRD 返回与请求匹配的策略（如果存在）。

6. MinIO Operator 将应用程序的组合策略信息发送到 MinIO Tenant。

7. 租户创建与请求策略匹配的临时凭证，并将其返回给 MinIO Operator。

8. MinIO Operator 将临时凭证转发回应用程序。

9. 应用程序使用凭据将对象存储调用发送到 MinIO 租户。

需求

MinIO Operator 的 STS 需要满足以下要求：

• MinIO Operator v5.0.0 或更高版本。

• 部署必须有TLS 已配置.

• （适用于 Operator v5.0.0 - 5.0.10 版本）OPERATOR_STS_ENABLED环境变量设置为on.

过程

1. 为部署启用 STS 功能

   Note

   此步骤对于 Operator 5.0.11 或更高版本是可选的。

   kubectl -n minio-operator set env deployment/minio-operator OPERATOR_STS_ENABLED=on
   

   • 替换minio-operator使用您的部署命名空间。

   • 替换deployment/minio-operator使用您的部署的 MinIO Operator 的值。

     您可以通过运行以下命令找到部署值：kubectl get deployments -n <namespace>, 您替换<namespace>MinIO Operator 的命名空间。 您的 MinIO Operator 命名空间通常是minio-operator不过这个值在安装过程中可能会改变。

2. 确保适当的政策MinIO租户上存在供应用程序使用的策略

   下一步使用YAML文档，通过名为PolicyBinding.

3. 创建 Service Account 和 Policy Binding 的 YAML 资源：

   • 创建服务账户在 MinIO 租户中供应用程序使用。

     有关 Kubernetes 中服务账户的更多信息，请参阅Kubernetes 文档.

   • 创建一个策略绑定在目标租户的命名空间中，将应用程序链接到一个或多个 MinIO 租户策略。

4. 应用 YAML 文件以在部署中创建资源

   kubectl apply -k path/to/yaml/file.yaml
   

5. 使用支持该功能的SDKAssumeRoleWithWebIdentity类似行为，从您的应用程序向部署发送调用

   STS API期望在Kubernetes环境中存在服务账户的JWT。 当关联到pod时，例如通过deployment的.spec.spec.serviceAccountNamefield, Kubernetes 挂载一个JWT从已知位置（例如/var/run/secrets/kubernetes.io/serviceaccount/token.

   或者，您可以将令牌路径定义为环境变量：

   AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/kubernetes.io/serviceaccount/token
   

   以下 MinIO SDK 支持AssumeRoleRoleWithWebIdentity:

   • Golang

   • Java

   • JavaScript

   • .NET

   • Python

   有关使用 SDK 承担角色的示例，请参阅GitHub.

示例资源

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: sts-client # The namespace to add the service account to. Usually a tenant, but can be any namespace in the deployment.
  name: stsclient-sa # The name to use for the service account.

apiVersion: sts.min.io/v1alpha1
kind: PolicyBinding
metadata:
  name: binding-1
  namespace: minio-tenant-1 # The namespace of the tenant this binding is for
spec:
  application:
    namespace: sts-client # The namespace that contains the service account for the application
    serviceaccount: stsclient-sa # The service account to use for the application
  policies:
    - test-bucket-rw # A policy that already exists in the tenant
    # - test-bucket-policy-2 # Add as many policies as needed

参考

• STS Examples by SDK

• Kubernetes 关于服务账户的文档

• MinIO STS API