Helm 用户指南-系列（7）-RBAC-优快云博客

本文详细介绍了如何在Kubernetes中使用基于角色的访问控制(RBAC)来管理Helm的权限，包括Tiller服务帐户的权限配置，以及如何限制Tiller在特定namespace的操作范围。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

RBAC-基于角色的访问控制

在Kubernetes中，最佳的做法是，为特定的应用程序的服务帐户授予角色,确保应用程序在指定的范围内运行。要详细了解服务帐户权限请阅读官方Kubernetes文档.

Bitnami写了一个在集群中配置RBAC的指导，可让你了解RBAC基础知识。

我在网址 https://whmzsu.github.io/helm-doc-zh-cn/ 不断更新，同时也会搬运到这里，大家有兴趣加入https://github.com/whmzsu/helm-doc-zh-cn/的可以给我提交意见和建议。

本指南面向希望对Helm限制如下权限的用户:

Tiller将资源安装到特定namespace能力
授权Helm客户端对Tiller实例的访问

Tiller和基于角色的访问控制

可以在配置Helm时使用--service-account <NAME>参数将服务帐户添加到Tiller 。前提条件是必须创建一个角色绑定，来指定预先设置的角色role和服务帐户service account 名称。

在前提条件下，并且有了一个具有正确权限的服务帐户，就可以像这样运行一个命令来初始化Tiller： helm init --service-account <NAME>

Example: 服务账户带有cluster-admin 角色权限

$ kubectl create serviceaccount tiller --namespace kube-system
serviceaccount "tiller" created

文件 rbac-config.yaml:

apiVersion: v1
kind: ServiceAccount metadata: name: tiller
 namespace: kube-system
--- apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding metadata: name: tiller
roleRef: apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole name: cluster-admin
subjects: - kind: ServiceAccount name: tiller
 namespace: kube-system

Note: cluster-admin角色是在Kubernetes集群中默认创建的，因此不必再显式地定义它。.

$ kubectl create -f rbac-config.yaml
serviceaccount "tiller" created
clusterrolebinding "tiller" created
$ helm init --service-account tiller

在特定namespace中部署Tiller，并仅限于在该namespace中部署资源

在上面的例子中，我们让Tiller管理访问整个集群。当然，Tiller正常工作并不一定要为它设置集群管理员访问权限。我们可以指定Role和RoleBinding来将Tiller的范围限制为特定的namespace，而不是指定ClusterRole或ClusterRoleBinding。

$ kubectl create namespace tiller-world
namespace "tiller-world" created
$ kubectl create serviceaccount tiller --namespace tiller-world
serviceaccount "tiller" created

定义允许Tiller管理namespace tiller-world 中所有资源的角色，文件role-tiller.yaml:

kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: name: tiller-manager
 namespace: tiller-world
rules: - apiGroups: ["", "extensions", "apps"] resources: ["*"] verbs: ["*"]

$ kubectl create -f role-tiller.yaml
role "tiller-manager" created

文件 rolebinding-tiller.yaml,

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: name: tiller-binding
 namespace: tiller-world
subjects: - kind: ServiceAccount name: tiller
 namespace: tiller-world
roleRef: kind: Role name: tiller-manager
 apiGroup: rbac.authorization.k8s.io

$ kubectl create -f rolebinding-tiller.yaml
rolebinding "tiller-binding" created

之后，运行helm init来在tiller-world namespace中安装Tiller 。

$ helm init --service-account tiller --tiller-namespace tiller-world
$HELM_HOME has been configured at /Users/awesome-user/.helm. Tiller (the Helm server side component) has been installed into your Kubernetes Cluster. Happy Helming!

$ helm install nginx --tiller-namespace tiller-world --namespace tiller-world
NAME: wayfaring-yak
LAST DEPLOYED: Mon Aug 7 16:00:16 2017
NAMESPACE: tiller-world
STATUS: DEPLOYED

RESOURCES: ==> v1/Pod
NAME READY STATUS RESTARTS AGE
wayfaring-yak-alpine 0/1 ContainerCreating 0 0s

Example: 在一个namespace中部署Tiller，并限制它在另一个namespace部署资源

在上面的例子中，我们让Tiller管理它部署所在的namespace。现在，让我们限制Tiller的范围，将资源部署在不同的namespace中！

下面例子中，让我们在myorg-system namespace中安装Tiller，并允许Tiller在myorg-users namespace中部署资源。

$ kubectl create namespace myorg-system
namespace "myorg-system" created
$ kubectl create serviceaccount tiller --namespace myorg-system
serviceaccount "tiller" created

在role-tiller.yaml中，定义了一个允许Tiller管理所有myorg-users资源的角色：

kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: name: tiller-manager
 namespace: myorg-users
rules: - apiGroups: ["", "extensions", "apps"] resources: ["*"] verbs: ["*"]

$ kubectl create -f role-tiller.yaml
role "tiller-manager" created

将 service account 与那个role绑定. rolebinding-tiller.yaml,

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: name: tiller-binding
 namespace: myorg-users
subjects: - kind: ServiceAccount name: tiller
 namespace: myorg-system
roleRef: kind: Role name: tiller-manager
 apiGroup: rbac.authorization.k8s.io

$ kubectl create -f rolebinding-tiller.yaml
rolebinding "tiller-binding" created

我们还需要授予Tiller访问权限来读取myorg-system中的configmaps，以便它可以存储release信息。如 role-tiller-myorg-system.yaml:

kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: namespace: myorg-system
 name: tiller-manager
rules: - apiGroups: ["", "extensions", "apps"] resources: ["configmaps"] verbs: ["*"]

$ kubectl create -f role-tiller-myorg-system.yaml
role "tiller-manager" created

相应的role 绑定. 如 rolebinding-tiller-myorg-system.yaml:

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: name: tiller-binding
 namespace: myorg-system
subjects: - kind: ServiceAccount name: tiller
 namespace: myorg-system
roleRef: kind: Role name: tiller-manager
 apiGroup: rbac.authorization.k8s.io

$ kubectl create -f rolebinding-tiller-myorg-system.yaml
rolebinding "tiller-binding" created

Helm 和基于角色的访问控制

在pod中运行Helm客户端时，为了让Helm客户端与Tiller实例进行通信，需要授予某些特权。具体来说，Helm客户端需要能够创建pods，转发端口并能够在Tiller运行的namespace中列出pod（这样它才可以找到Tiller）。

Example: 在一个namespace中部署helm，与在另一个namespace中与Tiller交互

在这个例子中，我们将假设Tiller在名为tiller-world 的namespace中运行，并且Helm客户端在helm-world中运行。默认情况下，Tiller在kube-system namespace中运行。

如 helm-user.yaml:

apiVersion: v1
kind: ServiceAccount metadata: name: helm
 namespace: helm-world
--- apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role metadata: name: tiller-user
 namespace: tiller-world
rules: - apiGroups: - "" resources: - pods/portforward
 verbs: - create
- apiGroups: - "" resources: - pods
 verbs: - list
--- apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding metadata: name: tiller-user-binding
 namespace: tiller-world
roleRef: apiGroup: rbac.authorization.k8s.io
 kind: Role name: tiller-user
subjects: - kind: ServiceAccount name: helm
 namespace: helm-world

$ kubectl create -f helm-user.yaml
serviceaccount "helm" created
role "tiller-user" created
rolebinding "tiller-user-binding" created

本文转自kubernetes中文社区- Helm 用户指南-系列（7）-RBAC