Authorizing the data collector to access Kubernetes resources

To monitor applications that are running in IBM® Cloud Private, the service account that you use to configure the runtime data collector must have access to Kubernetes resources through Kubernetes API. Otherwise, you must authorize the service account with appropriate access before you configure the data collector.

About this task

The service account that you use to install and configure the data collector must have access to Kubernetes resources. To determine whether the data collector has access to resources, you can use this service account to run the following commands on the Kubernetes master node:

kubectl auth can-i list nodes --all-namespaces --as system:serviceaccount:namespace:service_account_name
kubectl auth can-i get nodes --all-namespaces --as system:serviceaccount:namespace:service_account_name
kubectl auth can-i get pods --all-namespaces --as system:serviceaccount:namespace:service_account_name
kubectl auth can-i list services --all-namespaces --as system:serviceaccount:namespace:service_account_name
kubectl auth can-i get services --all-namespaces --as system:serviceaccount:namespace:service_account_name
kubectl auth can-i get configmaps --all-namespaces --as system:serviceaccount:namespace:service_account_name
kubectl auth can-i get deployments --all-namespaces --as system:serviceaccount:namespace:service_account_name

Where namespace is the namespace of your environment and service_account_name is the name of the service account that you use to configure the data collector. By default, the service_account_name is default. You must change the namespace and service_account_name with the values that you use.

Tip: To determine the existing service_account_name of a pod, you can run the command kubectl get po my_pod_name -o yaml | grep serviceAccount, where my_pod_name is the name of the running pod.

See the following example:

kubectl auth can-i list nodes --all-namespaces --as system:serviceaccount:ops-am:default
kubectl auth can-i get nodes --all-namespaces --as system:serviceaccount:ops-am:default
kubectl auth can-i get pods --all-namespaces --as system:serviceaccount:ops-am:default
kubectl auth can-i list services --all-namespaces --as system:serviceaccount:ops-am:default
kubectl auth can-i get services --all-namespaces --as system:serviceaccount:ops-am:default
kubectl auth can-i get configmaps --all-namespaces --as system:serviceaccount:ops-am:default
kubectl auth can-i get deployments --all-namespaces --as system:serviceaccount:ops-am:default

If you get at least one response of the commands to be no, it means that you do not have required permissions. Do the following steps to grant required service account that is used to set up your application.

Procedure

Create a ClusterRole yaml file (for example, name it as lwdc-clusterrole.yaml) to allow read permission to required Kubernetes resources.

Here is an example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: lwdc-query
rules:
- apiGroups:
  - ""
  - "apps"
  resources:
  - nodes
  - services
  - configmaps
  - pods
  - deployments
  verbs:
  - list
  - get

Run the following command to create the ClusterRole:
```
# kubectl create -f lwdc-clusterrole.yaml
```

Create a ClusterRoleBinding yaml file (for example, name it as lwdc-rolebinding.yaml) to bind the service account to the ClusterRole that is created in step 1 and 2. This ClusterRole has access permission to query Kubernetes resources in the RBAC mode.

The following example binds the system:serviceaccount:ops-am:default account to the specific ClusterRole.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: lwdc-rolebinding
  namespace: ops-am
subjects:
- kind: User
  name: system:serviceaccount:ops-am:default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: lwdc-query
  apiGroup: rbac.authorization.k8s.io

If you need to grant the access to multiple service accounts in cluster scope, you can also create the ClusterRoleBinding against service account group, for example:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: lwdc-rolebinding
  namespace: ops-am
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: lwdc-query
  apiGroup: rbac.authorization.k8s.io

Run the following command:

# kubectl create -f clusterrolebinding.yaml