0

我目前正面临目前的情况。我想让用户访问各个命名空间，这样他们就可以

  • 使用 Helm 图表创建和部署资源（例如，来自 Bitnami）

另一方面，用户不应该

  • 创建/检索/修改/删除 RBAC 设置，如 ServiceAccounts、RoleBindings、Roles、NetworkPolicies
  • 掌握与 ServiceAccounts 相关的秘密

当然，关键是在这里为它定义最好的角色。可能，以下不是最好的主意：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role
  namespace: example-namespace
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

因此，如果你能提出一些明智的方法，用户可以尽可能自由地使用它，但不要接触一些更“危险”的资源，那就太好了。

本质上，我想遵循此处概述的工作流程 ( https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html )。所以最重要的是，一个命名空间中的单个用户无法读取同一命名空间中用户的秘密，因此他们无法使用其他人的凭据进行身份验证。

4

2 回答 2

1

我认为以下策略将有所帮助：

  1. RBAC 仅限制对自己命名空间的服务帐户的访问。
  2. 确保automountServiceAccountToken: false使用策略在秘密和 POD 级别。当出现节点安全漏洞时，这有助于保护机密。密钥仅在执行时可用，不会存储在 POD 中。

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server

  1. 使用 kms 加密存储在 ETCD 中的机密（推荐）。但是，如果您没有 km​​s 提供商，那么您也可以选择其他提供商以确保最低安全性。

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers

于 2021-12-29T10:48:41.470 回答
0

听起来 ClusterRole 编辑几乎可以满足您的需求。 https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles

它将允许访问秘密“但是，此角色允许访问 Secrets 并作为命名空间中的任何 ServiceAccount 运行 Pod，因此它可用于获取命名空间中任何 ServiceAccount 的 API 访问级别。”

于 2021-12-29T09:55:02.720 回答