github.com/y-taka-23/helm@v2.8.0+incompatible/docs/rbac.md (about) 1 # Role-based Access Control 2 3 In Kubernetes, granting a role to an application-specific service account is a best practice to ensure that your application is operating in the scope that you have specified. Read more about service account permissions [in the official Kubernetes docs](https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions). 4 5 Bitnami also has a fantastic guide for [configuring RBAC in your cluster](https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/) that takes you through RBAC basics. 6 7 This guide is for users who want to restrict tiller's capabilities to install resources to certain namespaces, or to grant a helm client running access to a tiller instance. 8 9 ## Tiller and Role-based Access Control 10 11 You can add a service account to Tiller using the `--service-account <NAME>` flag while you're configuring helm. As a prerequisite, you'll have to create a role binding which specifies a [role](https://kubernetes.io/docs/admin/authorization/rbac/#role-and-clusterrole) and a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) name that have been set up in advance. 12 13 Once you have satisfied the pre-requisite and have a service account with the correct permissions, you'll run a command like this: `helm init --service-account <NAME>` 14 15 ### Example: Service account with cluster-admin role 16 17 ```console 18 $ kubectl create serviceaccount tiller --namespace kube-system 19 serviceaccount "tiller" created 20 ``` 21 22 In `rbac-config.yaml`: 23 24 ```yaml 25 apiVersion: v1 26 kind: ServiceAccount 27 metadata: 28 name: tiller 29 namespace: kube-system 30 --- 31 apiVersion: rbac.authorization.k8s.io/v1beta1 32 kind: ClusterRoleBinding 33 metadata: 34 name: tiller 35 roleRef: 36 apiGroup: rbac.authorization.k8s.io 37 kind: ClusterRole 38 name: cluster-admin 39 subjects: 40 - kind: ServiceAccount 41 name: tiller 42 namespace: kube-system 43 ``` 44 45 _Note: The cluster-admin role is created by default in a Kubernetes cluster, so you don't have to define it explicitly._ 46 47 ```console 48 $ kubectl create -f rbac-config.yaml 49 serviceaccount "tiller" created 50 clusterrolebinding "tiller" created 51 $ helm init --service-account tiller 52 ``` 53 54 ### Example: Deploy tiller in a namespace, restricted to deploying resources only in that namespace 55 56 In the example above, we gave Tiller admin access to the entire cluster. You are not at all required to give Tiller cluster-admin access for it to work. Instead of specifying a ClusterRole or a ClusterRoleBinding, you can specify a Role and RoleBinding to limit Tiller's scope to a particular namespace. 57 58 ```console 59 $ kubectl create namespace tiller-world 60 namespace "tiller-world" created 61 $ kubectl create serviceaccount tiller --namespace tiller-world 62 serviceaccount "tiller" created 63 ``` 64 65 Define a Role that allows tiller to manage all resources in `tiller-world` like in `role-tiller.yaml`: 66 67 ```yaml 68 kind: Role 69 apiVersion: rbac.authorization.k8s.io/v1beta1 70 metadata: 71 name: tiller-manager 72 namespace: tiller-world 73 rules: 74 - apiGroups: ["", "extensions", "apps"] 75 resources: ["*"] 76 verbs: ["*"] 77 ``` 78 79 ```console 80 $ kubectl create -f role-tiller.yaml 81 role "tiller-manager" created 82 ``` 83 84 In `rolebinding-tiller.yaml`, 85 86 ```yaml 87 kind: RoleBinding 88 apiVersion: rbac.authorization.k8s.io/v1beta1 89 metadata: 90 name: tiller-binding 91 namespace: tiller-world 92 subjects: 93 - kind: ServiceAccount 94 name: tiller 95 namespace: tiller-world 96 roleRef: 97 kind: Role 98 name: tiller-manager 99 apiGroup: rbac.authorization.k8s.io 100 ``` 101 102 ```console 103 $ kubectl create -f rolebinding-tiller.yaml 104 rolebinding "tiller-binding" created 105 ``` 106 107 Afterwards you can run `helm init` to install tiller in the `tiller-world` namespace. 108 109 ```console 110 $ helm init --service-account tiller --tiller-namespace tiller-world 111 $HELM_HOME has been configured at /Users/awesome-user/.helm. 112 113 Tiller (the helm server side component) has been installed into your Kubernetes Cluster. 114 Happy Helming! 115 116 $ helm install nginx --tiller-namespace tiller-world --namespace tiller-world 117 NAME: wayfaring-yak 118 LAST DEPLOYED: Mon Aug 7 16:00:16 2017 119 NAMESPACE: tiller-world 120 STATUS: DEPLOYED 121 122 RESOURCES: 123 ==> v1/Pod 124 NAME READY STATUS RESTARTS AGE 125 wayfaring-yak-alpine 0/1 ContainerCreating 0 0s 126 ``` 127 128 ### Example: Deploy tiller in a namespace, restricted to deploying resources in another namespace 129 130 In the example above, we gave Tiller admin access to the namespace it was deployed inside. Now, let's limit Tiller's scope to deploy resources in a different namespace! 131 132 For example, let's install tiller in the namespace `myorg-system` and allow tiller to deploy resources in the namespace `myorg-users`. 133 134 ```console 135 $ kubectl create namespace myorg-system 136 namespace "myorg-system" created 137 $ kubectl create serviceaccount tiller --namespace myorg-system 138 serviceaccount "tiller" created 139 ``` 140 141 Define a Role that allows tiller to manage all resources in `myorg-users` like in `role-tiller.yaml`: 142 143 ```yaml 144 kind: Role 145 apiVersion: rbac.authorization.k8s.io/v1beta1 146 metadata: 147 name: tiller-manager 148 namespace: myorg-users 149 rules: 150 - apiGroups: ["", "extensions", "apps"] 151 resources: ["*"] 152 verbs: ["*"] 153 ``` 154 155 ```console 156 $ kubectl create -f role-tiller.yaml 157 role "tiller-manager" created 158 ``` 159 160 Bind the service account to that role. In `rolebinding-tiller.yaml`, 161 162 ```yaml 163 kind: RoleBinding 164 apiVersion: rbac.authorization.k8s.io/v1beta1 165 metadata: 166 name: tiller-binding 167 namespace: myorg-users 168 subjects: 169 - kind: ServiceAccount 170 name: tiller 171 namespace: myorg-system 172 roleRef: 173 kind: Role 174 name: tiller-manager 175 apiGroup: rbac.authorization.k8s.io 176 ``` 177 178 ```console 179 $ kubectl create -f rolebinding-tiller.yaml 180 rolebinding "tiller-binding" created 181 ``` 182 183 We'll also need to grant tiller access to read configmaps in myorg-system so it can store release information. In `role-tiller-myorg-system.yaml`: 184 185 ```yaml 186 kind: Role 187 apiVersion: rbac.authorization.k8s.io/v1beta1 188 metadata: 189 namespace: myorg-system 190 name: tiller-manager 191 rules: 192 - apiGroups: ["", "extensions", "apps"] 193 resources: ["configmaps"] 194 verbs: ["*"] 195 ``` 196 197 ```console 198 $ kubectl create -f role-tiller-myorg-system.yaml 199 role "tiller-manager" created 200 ``` 201 202 And the respective role binding. In `rolebinding-tiller-myorg-system.yaml`: 203 204 ```yaml 205 kind: RoleBinding 206 apiVersion: rbac.authorization.k8s.io/v1beta1 207 metadata: 208 name: tiller-binding 209 namespace: myorg-system 210 subjects: 211 - kind: ServiceAccount 212 name: tiller 213 namespace: myorg-system 214 roleRef: 215 kind: Role 216 name: tiller-manager 217 apiGroup: rbac.authorization.k8s.io 218 ``` 219 220 ```console 221 $ kubectl create -f rolebinding-tiller-myorg-system.yaml 222 rolebinding "tiller-binding" created 223 ``` 224 225 ## Helm and Role-based Access Control 226 227 When running a helm client in a pod, in order for the helm client to talk to a tiller instance, it will need certain privileges to be granted. Specifically, the helm client will need to be able to create pods, forward ports and be able to list pods in the namespace where tiller is running (so it can find tiller). 228 229 ### Example: Deploy Helm in a namespace, talking to Tiller in another namespace 230 231 In this example, we will assume tiller is running in a namespace called `tiller-world` and that the helm client is running in a namespace called `helm-world`. By default, tiller is running in the `kube-system` namespace. 232 233 In `helm-user.yaml`: 234 235 ```yaml 236 apiVersion: v1 237 kind: ServiceAccount 238 metadata: 239 name: helm 240 namespace: helm-world 241 --- 242 apiVersion: rbac.authorization.k8s.io/v1beta1 243 kind: Role 244 metadata: 245 name: tiller-user 246 namespace: tiller-world 247 rules: 248 - apiGroups: 249 - "" 250 resources: 251 - pods/portforward 252 verbs: 253 - create 254 - apiGroups: 255 - "" 256 resources: 257 - pods 258 verbs: 259 - list 260 --- 261 apiVersion: rbac.authorization.k8s.io/v1beta1 262 kind: RoleBinding 263 metadata: 264 name: tiller-user-binding 265 namespace: tiller-world 266 roleRef: 267 apiGroup: rbac.authorization.k8s.io 268 kind: Role 269 name: tiller-user 270 subjects: 271 - kind: ServiceAccount 272 name: helm 273 namespace: helm-world 274 ``` 275 276 ```console 277 $ kubectl create -f helm-user.yaml 278 serviceaccount "helm" created 279 role "tiller-user" created 280 rolebinding "tiller-user-binding" created 281 ```