RBAC requirements

To expose the backing service binding data using the Service Binding Operator, you require certain Role-based access control (RBAC) permissions. Specify certain verbs under the rules field of the ClusterRole resource to grant the RBAC permissions for the backing service resources. When you define these rules, you allow the Service Binding Operator to read the binding data of the backing service resources throughout the cluster. If the users do not have permissions to read binding data or modify application resource, the Service Binding Operator prevents such users to bind services to application. Adhering to the RBAC requirements avoids unnecessary permission elevation for the user and prevents access to unauthorized services or applications.

The Service Binding Operator performs requests against the Kubernetes API using a dedicated service account. By default, this account has permissions to bind services to workloads, both represented by the following standard Kubernetes or OpenShift objects:

The Operator service account is bound to an aggregated cluster role, allowing Operator providers or cluster administrators to enable binding custom service resources to workloads. To grant the required permissions within a ClusterRole, label it with the servicebinding.io/controller flag and set the flag value to true. The following example shows how to allow the Service Binding Operator to get, watch, and list the custom resources (CRs) of Percona MongoDB Operator:

Example: Enable binding to MongoDB instances provisioned by Percona MongoDB Operator
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
  name: percona-mongodb-view
    servicebinding.io/controller: "true"
  - apiGroups:
      - psmdb.percona.com
      - perconaservermongodbs
      - perconaservermongodbs/status
      - get
      - watch
      - list

This cluster role can be deployed during the installation of the backing service Operator. You can add it as part of the manifests.