Kubernetes用户在单个命名空间上工作的角色定义

Question

我目前正面临当前的情况。我想让用户访问单独的名称空间，这样他们就可以

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

另一方面，用户不应该使用

• 创建/检索/修改/删除RBAC设置，如ServiceAccounts、RoleBindings、Roles、NetworkPolicies
• 获取与ServiceAccount相关的机密

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

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)。因此，最重要的是，一个命名空间中的单个用户无法读取同一命名空间中用户的机密，因此他们无法使用其他人的凭据进行身份验证。

Answer 1

在我看来，以下策略将有所帮助：

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

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-访问api服务器的默认服务帐户

3. 使用kms加密存储在ETCD中的机密(推荐(。但如果你没有kms提供商，那么你也可以选择其他提供商来确保最低的安全性

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

Answer 2

听起来ClusterRole编辑几乎符合您的需求。https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-面对角色

它将允许访问机密"；但是，此角色允许访问Secrets并将Pods作为命名空间中的任何ServiceAccount运行，因此它可以用于获得命名空间中任何ServiceAccount的API访问级别">