锁定 MinIO 操作员权限

虽然您可以使用 deployment 或 statefulset 在 Kubernetes 上部署 MinIO，但在 Kubernetes 上部署 MinIO 的推荐方法是通过官方的 MinIO Operator。为什么？

MinIO Operator 简化了 Kubernetes 集群上的 MinIO 管理，不仅在初始部署期间（第 0 天和第 1 天），而且在正在进行的第 2 天操作期间。例如，通过添加服务器池来扩展集群时，只需运行几个 kubectl 命令即可。有关更多详细信息，请参阅使用池扩展 MinIO 群集。

MinIO Operator 支持将 MinIO 租户部署到任何云、本地、边缘或混合环境中的 Kubernetes 集群上，基本上是在可以运行 Kubernetes 集群的任何地方。MinIO Operator 使用自定义资源定义 （CRD） 和 Kubernetes 插件安装该插件，该 krew 插件提供了使用 kubectl minio 命令管理 MinIO 租户的能力。

下面我们来详细看一下上面的图表。MiniO Operator 将部署在专用命名空间中;我们稍后将向您展示这如何派上用场。命名空间由 2 个 Pod 组成：

Operator：Operator Pod 负责租户的维护，如部署、管理、修改等操作。

控制台：控制台 pod 是一个图形界面，用于执行与使用 kubectl minio 命令使用 CLI 类似的功能。

除此之外，MinIO Operator 部署的每个租户都需要位于单独的命名空间中。它还需要在 pod 中创建以下 3 个容器。

初始化容器：用于在启动时配置主 MinIO 容器，一旦 MinIO 容器启动，此容器就会终止。

MinIO 容器：这是运行 MinIO 的容器（类似于单个裸机安装）。这是租户最终附加持久性卷声明 （PVC） 以与存储对象的持久性卷 （PV） 通信的容器。

Sidecar 容器：这是一个容器，用于监视群集中的各种操作，例如租户的配置机密和根凭据。如果这些被更改，它们将自动更新。MinIO 还构建了一个名为 Sidekick 的 sidecar 容器，这是一个微型负载均衡器，作为 sidecar 连接到每个客户端应用程序进程;您可以消除集中式负载均衡器瓶颈和 DNS 故障转移管理。Sidekick 通过就绪 API 和 HTTP 错误返回检查其运行状况，从而自动避免将流量发送到故障服务器。

如您所见，部署 MinIO 集群需要多个移动部件，例如容器、命名空间和 PVC。这些移动部件需要特定权限才能执行其操作。虽然我们始终遵循安全最佳实践，并将 MinIO Operator 设计为使用尽可能少的权限，但有时必须进一步锁定 MinIO 部署，以满足金融和医疗保健等领域的监管要求，这些领域存储了 AI/ML 和其他敏感数据/IP 的模型。

在这篇文章中，我们将向您展示如何为MinIO Operator配置最严格的命名空间权限，同时能够充分利用MinIO Operator的强大功能和灵活性进行日常操作。

如何锁定操作员

在完成锁定 MinIO Operator 的过程时，我们假设您熟悉 Kubernetes 的概念和过程。虽然我们可能会向你展示一些最佳实践，但这篇博文并不能替代 Kubernetes 文档。考虑到这一点，让我们开始吧。

我们将使用 Kustomize 安装 MinIO Operator，请务必事先按照这些说明安装 Kustomize。

生成 operator.yaml 文件并将所有资源连接到一个文件中

kustomize build github.com/minio/operator/resources/\?ref\=v5.0.9 > operator.yaml
1

打开 operator.yaml .以下部分将与 console-sa-role 和 console-sa-binding 相关。删除与这两个设置相关的所有内容。

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  name: console-sa-role

rules:

…

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: console-sa-binding

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: console-sa-role

subjects:

  - kind: ServiceAccount

	name: console-sa

	namespace: default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

请注意，由于规则数量的原因，上述 yaml 已被截断。我们向您展示了 yaml 的开头和结尾，请务必删除这两个部分之间的所有内容。

我们将删除默认情况下授予控制台的宽松权限。这样做的缺点是，由于令牌将仅限于操作员的集群角色，因此 JWT 控制台 UI 将不再能够创建命名空间或删除卷。这些任务必须在操作员的自动化范围之外手动完成。

从中删除 console-sa-role operator.yaml 和 console-sa-binding 资源后，应用其余资源。

kubectl apply -f operator.yaml
1

通常，下一步是使用以下命令通过端口转发访问租户控制台

kubectl minio proxy
1

但在本例中，尽管我们可以访问 UI，但由于包含控制台的锁定命名空间，我们无法创建任何租户。那么，我们如何部署租户呢？让我们再次使用 Kustomize 来生成部署租户所需的资源的 yaml。

kustomize build github.com/minio/operator/examples/kustomization/tenant-lite\?ref\=v5.0.9 > tenant.yaml

1
2

构建租户 yaml 后，可以按如下方式部署它

kubectl apply -f tenant.yaml

1
2

让我们进行测试，以确保我们可以访问新创建的租户

# mc alias set myminio https://minio.tenant-lite.svc.cluster.local:443 minio minio123
Added `myminio` successfully.
1
2

创建存储桶以验证它是否已创建

root@ubuntu:/# mc mb myminio/ajtest
Bucket created successfully `myminio/ajtest`.
1
2

检查 MinIO 群集和纠删集的状态

root@ubuntu:/# mc admin info myminio

●  myminio-pool-0-0.myminio-hl.tenant-lite.svc.cluster.local:9000

   Uptime: 3 minutes

   Version: 2024-01-09T19:57:37Z

   Network: 4/4 OK

   Drives: 2/2 OK

   Pool: 1


●  myminio-pool-0-1.myminio-hl.tenant-lite.svc.cluster.local:9000

   Uptime: 3 minutes

   Version: 2024-01-09T19:57:37Z

   Network: 4/4 OK

   Drives: 2/2 OK

   Pool: 1


●  myminio-pool-0-2.myminio-hl.tenant-lite.svc.cluster.local:9000

   Uptime: 3 minutes

   Version: 2024-01-09T19:57:37Z

   Network: 4/4 OK

   Drives: 2/2 OK

   Pool: 1


●  myminio-pool-0-3.myminio-hl.tenant-lite.svc.cluster.local:9000

   Uptime: 3 minutes

   Version: 2024-01-09T19:57:37Z

   Network: 4/4 OK

   Drives: 2/2 OK

   Pool: 1


Pools:

   1st, Erasure sets: 1, Drives per erasure set: 8


8 drives online, 0 drives offline

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

最后的思考

我们以简单易用为指导原则构建了 MinIO Operator。我们不会捆绑只会增加攻击面的额外功能，并且默认安装尽可能开箱即用，从而消除了过于宽松的访问进行配置的风险 - MinIO 操作员仅拥有执行其操作所需的权限。

在某些环境中，可能需要进一步锁定 MinIO Operator。集群角色访问真正需要的唯一权限是控制台 Pod，您可以对 kubectl minio 和 的组合使用来 mc 管理集群。

或者，如果公司安全标准要求这样做，您可以考虑使用角色而不是群集角色在同一命名空间中部署操作员和租户。这不是我们建议的最佳方法，但如果您需要将所有内容限制为单个命名空间，这是一种折衷方案。

MinIO Kubernetes 部署主要设计用于 Operator。MinIO Operator 不仅简化了 MinIO 集群的初始部署，还有助于在新版本发布时升级 MinIO 集群。最重要的是，MinIO Operator 允许您部署多个 MinIO 租户，并且允许您通过设置允许使用的空间量、存储桶数量等限制，在不同团队和部门之间逻辑地分离数据。它确实是一个强大的资源。