|
1 | 1 | # Configure RBAC permissions |
2 | 2 |
|
3 | | -`Microsoft.ApplicationInsights.Kubernetes` uses the service account to query kubernetes information to enhance telemetries. It is important to have proper permissions configured for kubernetes related information like node, pod and so on to be fetched correctly. |
| 3 | +`Microsoft.ApplicationInsights.Kubernetes` uses the service account to query Kubernetes information to enhance telemetries. It is important to have proper permissions configured for Kubernetes-related resources like Node, Pod, and so on to be fetched correctly. |
4 | 4 |
|
5 | | -In this post, we will start by describe a method to correctly configure the permissions for an RBAC enabled cluster. And then share a guidance for troubleshooting. |
| 5 | +In this post, we will start by describing a method to correctly configure the permissions for an RBAC-enabled cluster. And then share troubleshooting guidance. |
6 | 6 |
|
7 | 7 | ## Assumptions |
8 | 8 |
|
9 | 9 | In this demo, we will have the following assumptions. Please change the related values accordingly: |
10 | 10 |
|
11 | | -* The application will be deployed to namespace of `ai-k8s-demo`. |
| 11 | +* The application will be deployed to namespace `ai-k8s-demo`. |
12 | 12 | * The application will leverage the `default` service account. |
13 | 13 |
|
14 | | -## Configure ClusterRole and ClusterRoleBinding for the service account |
15 | | - |
16 | | -* Create a yaml file, [sa-role.yaml](./sa-role.yaml) for example. We will deploy it when it is ready. |
17 | | - |
18 | | - * Write spec to define a cluster role, name it `appinsights-k8s-property-reader` for example: |
19 | | - |
20 | | - ```yaml |
21 | | - kind: ClusterRole |
22 | | - apiVersion: rbac.authorization.k8s.io/v1 |
23 | | - metadata: |
24 | | - # "namespace" omitted since ClusterRoles are not namespaced |
25 | | - name: appinsights-k8s-property-reader |
26 | | - rules: |
27 | | - - apiGroups: ["", "apps"] |
28 | | - resources: ["pods", "nodes", "replicasets", "deployments"] |
29 | | - verbs: ["get", "list"] |
30 | | - ``` |
31 | | - That spec defines the name of the role, and what permission does the role has, for example, list pods. |
32 | | - |
33 | | - You don't have to use the exact name, but you will need to making sure the name is referenced correctly in the following steps. |
34 | | - |
35 | | - * Append a Cluster role binding spec: |
36 | | - |
37 | | - ```yaml |
38 | | - --- |
39 | | - # actual binding to the role |
40 | | - kind: ClusterRoleBinding |
41 | | - apiVersion: rbac.authorization.k8s.io/v1 |
42 | | - metadata: |
43 | | - name: appinsights-k8s-property-reader-binding |
44 | | - subjects: |
45 | | - - kind: ServiceAccount |
46 | | - name: default |
47 | | - namespace: ai-k8s-demo |
48 | | - roleRef: |
49 | | - kind: ClusterRole |
50 | | - name: appinsights-k8s-property-reader |
51 | | - apiGroup: rbac.authorization.k8s.io |
52 | | - ``` |
53 | | -
|
54 | | - That is to grant the role of `appinsights-k8s-property-reader` to the default service account in namespace of `ai-k8s-demo`. |
55 | | - |
| 14 | +## Setup the permissions for the service account |
| 15 | + |
| 16 | +Depending on various considerations, there could be different strategies to set up the permissions for your service account. Here we list 2 common possibilities, as examples. |
| 17 | + |
| 18 | +* If you want to get the Node information along with other resource info like Pod, Deployment, and so on, a ClusterRole and a ClusterRoleBinding are required, and here's how to do it: |
| 19 | + |
| 20 | + * Create a yaml file, [sa-role.yaml](./sa-role.yaml) for example. We will deploy it when it is ready. |
| 21 | + |
| 22 | + * Write spec to define a cluster role, name it `appinsights-k8s-property-reader` for example: |
| 23 | + |
| 24 | + ```yaml |
| 25 | + kind: ClusterRole |
| 26 | + apiVersion: rbac.authorization.k8s.io/v1 |
| 27 | + metadata: |
| 28 | + # "namespace" omitted since ClusterRoles are not namespaced |
| 29 | + name: appinsights-k8s-property-reader |
| 30 | + rules: |
| 31 | + - apiGroups: ["", "apps"] |
| 32 | + resources: ["pods", "nodes", "replicasets", "deployments"] |
| 33 | + verbs: ["get", "list"] |
| 34 | + ``` |
| 35 | + That spec defines the name of the role, and what permission does the role has, for example, list pods. |
| 36 | + |
| 37 | + You don't have to use the exact name, but you will need to making sure the name is referenced correctly in the following steps. |
| 38 | + |
| 39 | + * Append a Cluster role binding spec: |
| 40 | + |
| 41 | + ```yaml |
| 42 | + --- |
| 43 | + # actual binding to the role |
| 44 | + kind: ClusterRoleBinding |
| 45 | + apiVersion: rbac.authorization.k8s.io/v1 |
| 46 | + metadata: |
| 47 | + name: appinsights-k8s-property-reader-binding |
| 48 | + subjects: |
| 49 | + - kind: ServiceAccount |
| 50 | + name: default |
| 51 | + namespace: ai-k8s-demo |
| 52 | + roleRef: |
| 53 | + kind: ClusterRole |
| 54 | + name: appinsights-k8s-property-reader |
| 55 | + apiGroup: rbac.authorization.k8s.io |
| 56 | + ``` |
| 57 | +
|
| 58 | + That is to grant the role of `appinsights-k8s-property-reader` to the default service account in the namespace of `ai-k8s-demo`. |
| 59 | + |
| 60 | + * If you don't want to create a Cluster Role, it is also possible to use Role and RoleBinding starting with Application Insights for Kubernetes 2.0.6+. Follow the example in [sa-role-none-cluster.yaml](./sa-role-none-cluster.yaml). In that case, you will not have node info on the telemetries. |
| 61 | + |
56 | 62 | * Now you can deploy it: |
57 | 63 |
|
58 | 64 | ```shell |
59 | 65 | kubectl create -f `sa-role.yaml` |
60 | 66 | ``` |
61 | 67 | See [sa-role.yaml](sa-role.yaml) for a full example. |
62 | 68 |
|
63 | | -> :warning: Check back for various permissions needed. Depends on the implementations, it may change in the over time. |
| 69 | +> :warning: Check back for various permissions needed. Depending on the properties we try to fetch, it may change over time. |
64 | 70 |
|
65 | 71 | ## Ad-hoc troubleshooting for permission |
66 | 72 |
|
67 | | -Kubectl provides an `auth --can-i` sub command for troubleshooting permissions. It supports impersonate the service account. We can leverage it for permission troubleshooting, for example: |
| 73 | +Kubectl provides an `auth --can-i` subcommand for troubleshooting permissions. It supports impersonating the service account. We can leverage it for permission troubleshooting, for example: |
68 | 74 |
|
69 | 75 | ```shell |
70 | 76 | kubectl auth can-i list pod --namespace ai-k8s-demo --as system:serviceaccount:ai-k8s-demo:default |
|
84 | 90 |
|
85 | 91 | ## Use SubjectAccessReview |
86 | 92 |
|
87 | | -Kubernetes also provides `SubjectAccessReview` to check permission for given user on target resource. |
| 93 | +Kubernetes also provides `SubjectAccessReview` to check permission for a given user on the target resource. |
88 | 94 |
|
89 | 95 | ### Basic usage |
90 | 96 |
|
@@ -147,7 +153,7 @@ Kubernetes also provides `SubjectAccessReview` to check permission for given use |
147 | 153 | * [subject-access-review-key.yaml](./subject-access-review-key.yaml): a subset of permissions for probing the RBAC settings. |
148 | 154 | * [subject-access-review-full.yaml](./subject-access-review-full.yaml): a full list of all permissions needed for RBAC settings in case any specific permission is missing. |
149 | 155 |
|
150 | | -Let us know if there's questions, suggestions by filing [issues](https://github.com/microsoft/ApplicationInsights-Kubernetes/issues). |
| 156 | +Let us know if there are questions or suggestions by filing [issues](https://github.com/microsoft/ApplicationInsights-Kubernetes/issues). |
151 | 157 |
|
152 | 158 | ## References |
153 | 159 |
|
|
0 commit comments