我试图了解授予kubernetes serviceaccount权限以执行部署，服务创建等的安全隐患。该角色是具有命名空间角色绑定的clusterrole。
用例正在使用服务帐户来自动化/编排集群中的某些任务。版本是1.16
答案 0 :(得分：0)
服务帐户可用于将不同的访问级别授予不同的目的。开发人员ClusterRole需要列出，获取和观看资源，但不能删除。但是管理员可以删除和创建资源。
如果您正在开发K8运算符，则运算符需要与集群通信以创建，更新和删除资源，然后运算符需要使用所有动词的ClusterRoleBinding服务。这样操作员就可以对资源执行所有操作。但不是将完全权限分配给常规部署的好习惯。
答案 1 :(得分：0)
让我讨论一下。
根据docs。
- 相比之下，
角色 总是_ 在特定名称空间内设置权限 __；创建角色时，必须指定其所属的名称空间
ClusterRole 是 是非命名空间资源 。资源具有不同的名称（Role和ClusterRole），因为Kubernetes对象总是必须命名空间或不命名空间。不能两者兼有。
角色绑定向一个或一组用户授予在角色中定义的权限。它包含一个主题列表（用户，组或服务帐户），以及对所授予角色的引用。 RoleBinding授予特定命名空间中的权限，而ClusterRoleBinding授予在群集范围内访问的权限。
- 如果要在名称空间中定义角色，请使用Role；如果要在群集范围内定义角色，请使用ClusterRole。
- 角色绑定可以引用同一命名空间中的任何角色 。 或者，RoleBinding可以引用ClusterRole并将该ClusterRole绑定到RoleBinding的命名空间 。如果要将ClusterRole绑定到群集中的所有名称空间，请使用ClusterRoleBinding。
所以回答您的问题-处理ClusterRoles肯定会带来安全风险。
best solution是要授予尽可能小的权限。
这个问题没有答案，因为您需要计划和测试您的应用程序/部署和kubernetes API之间的操作/权限。例如，在一个命名空间内或整个集群中使用命名空间或非命名空间的资源。
在您的示例中，如果您在同一个名称空间中工作，则可以简单地使用Role / Rolebinding。您可以使用ClusterRole / Rolebinding并通过附加的RoleBinding扩展权限，从而允许ServiceAccount将新的k8s对象创建到另一个命名空间中。
假设我们正在谈论要部署的ServiceAccount，在这里您可以找到有关"RBAC in Deployments: A use case"的好建议
如果您为部署创建ServiceAccount并创建适当的Role / ClusterRole和Rolebinding / ClusterRoleBinding：
您可以执行：
kubectl can-i get secrets --as=system:serviceaccount:[namespace]:[service_account_name] -n [target_namespace]
要进行测试，请同时查看Access Clusters Using the Kubernetes API。
此命令将向您显示是否特定的ServiceAccount（由Rolebinding / ClusterRolebinding中的主题定义的 ）具有权限（由Role / ClusteRole中的动词定义的 ）以获取指定名称空间中的机密（ 由资源Role / ClusterRole 定义）。
按照这种方法，您可以验证您的部署是否具有足够的权限来针对Kubernetes API执行所有必需的操作。
在Kubernetes中使用RBAC时，您应该考虑以下提到的主题：
拥有多个具有不同属性的用户，建立了适当的身份验证机制。
完全控制每个用户或一组用户可以执行哪些操作。
完全控制Pod中的每个进程可以执行哪些操作。 限制名称空间某些资源的可见性。