Helm 用户指南-系列(7)-RBAC

RBAC-基于角色的访问控制

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

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

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

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

  1. Tiller将资源安装到特定namespace能力
  2. 授权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
K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址