为什么 RabbitMQ Cluster Operator 需要对 Secret 进行集群范围的读取操作？

Question

我们已经在 kubernetes 集群上安装了 RabbitMQ Cluster Operator，我注意到 clusterRole 具有资源“secrets”和动词“get、list、watch、create、delete”。

作为组织中的中央 Kubernetes 管理团队，我们希望限制对 Secret 的访问，只是想了解运营商支持的用例是什么。

如果我在操作符启动时删除“get”和“list”动词，则会抛出错误：

Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User \"system:serviceaccount:namespace:rabbitmq-cluster-operator\" cannot list resource \"secrets\" in API group \"\" at the cluster scope\n"

为什么需要集群范围内的秘密访问？

Answer 1

根据 Kubernetes Operator Pattern，使用 Operator 的目的是像“管理一项服务或一组服务的人类操作员”一样行事。这意味着创建角色和绑定、服务和部署定义，以及最重要的是管理配置和机密。

RabbitMQ 文档讨论了一些使用机密的方式，例如 在创建新实例时将实例管理凭据存储在已知位置。

RabbitmqCluster 的管理凭据存储在名为 INSTANCE-default-user 的 Kubernetes 密钥中，其中 INSTANCE 是 RabbitmqCluster 对象的名称。 Kubernetes 使用 base64 对秘密进行编码。

仅此一项就需要集群级别的秘密

get, list, create, delete

，因为操作员无法提前知道将在哪些命名空间实例中创建。

无需扫描整个 RabbitMQ 操作员存储库，

watch

秘密进行更改也很常见，因此可以使用新证书或凭证自动重新加载或更新相关资源。

大多数 Kubernetes 操作员可以使用更具体的 RoleBindings 进行强化，以便仅在所需的命名空间中向它们授予秘密权限。这将替换等效的 ClusterRoleBinding（而不是在所需命名空间中使用 RoleBinding），但允许权限保留为单个 ClusterRole 以进行标准化。

您可以通过添加

OPERATOR_SCOPE_NAMESPACE

的配置来绕过集群级权限错误，如集群操作员环境变量中所述。

变量名称	设置后的效果	未设置时的效果
OPERATOR_SCOPE_NAMESPACE	命名空间或命名空间列表，操作员将协调并监视 RabbitmqClusters（独立于安装命名空间）。使用逗号分隔符，不带空格，例如“项目-1，项目-2，rabbitmq-测试”	所有命名空间都受到监视和协调