#Creating the Required RBAC Resources Automatically

The Alauda Build of OpenTelemetry v2 Operator automatically creates the necessary cluster-level RBAC resources when certain Collector components require access to Kubernetes resources across the cluster. For some components, such as the k8s_attributes processor or the k8s_objects receiver, additional RBAC permissions are needed beyond the default Operator scope.

#Automatic RBAC creation

The Operator can automatically create the required ClusterRole and ClusterRoleBinding resources when the OpenTelemetry Collector configuration includes components that require cluster-wide access.

The following are examples of components that typically require additional RBAC permissions:

• k8s_attributes processor: Requires permissions to query Pod, Namespace, Node, ReplicaSet, and Deployment resources for enriching telemetry data with Kubernetes metadata.
• k8s_objects receiver: Requires permissions to watch and list Kubernetes resources such as Events, Pods, and Nodes.
• kubelet_stats receiver: Requires permissions to access kubelet endpoints for node and pod metrics.
• resource_detection processor: Requires permissions to access Node resources for resource detection.

#Permissions required of the user creating the Collector

Automatic RBAC creation is subject to a privilege escalation check. When the Operator would generate a ClusterRole for an OpenTelemetryCollector resource, it verifies that the user submitting the resource also holds the permissions being granted. If the user does not hold them, the resource is rejected by the admission webhook.

• When the Collector uses a ServiceAccount created by the Operator, the full set of generated permissions is checked against the submitting user.
• When the Collector reuses an existing ServiceAccount through spec.serviceAccount, only the permissions that account is missing are checked.

If creating a Collector fails with a permissions error even though the Operator itself is correctly authorized, grant the submitting user the same permissions the Collector needs, or have a user who already holds them create the resource.

#Procedure

1. Create the ClusterRole:

   kubectl apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: generate-processors-rbac
   rules:
   - apiGroups:
     - rbac.authorization.k8s.io
     resources:
     - clusterrolebindings
     - clusterroles
     verbs:
     - create
     - delete
     - get
     - list
     - patch
     - update
     - watch
   EOF

2. Create the ClusterRoleBinding:

   kubectl apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: generate-processors-rbac
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: generate-processors-rbac
   subjects:
   - kind: ServiceAccount
     name: opentelemetry-operator-controller-manager
     namespace: opentelemetry-operator2
   EOF

3. (Optional) Restart the Alauda Build of OpenTelemetry v2 Operator to pick up the new RBAC permissions:

   TIP

   This step is only required if the Operator was already running before you created the ClusterRole and ClusterRoleBinding. If you created them before installing the Operator, you can skip this step.

   kubectl delete pod -n opentelemetry-operator2 -l app.kubernetes.io/name=opentelemetry-operator

#Removing the RBAC resources

When you no longer need the Operator to create cluster-level RBAC resources automatically, remove the ClusterRole and ClusterRoleBinding created in the Procedure section to release the granted permissions.

Procedure

Execute the following commands to remove the RBAC resources:

kubectl delete clusterrolebinding generate-processors-rbac --ignore-not-found
kubectl delete clusterrole generate-processors-rbac --ignore-not-found