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
list the custom resources (CRs) of Percona MongoDB Operator:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: percona-mongodb-view labels: servicebinding.io/controller: "true" rules: - apiGroups: - psmdb.percona.com resources: - perconaservermongodbs - perconaservermongodbs/status verbs: - 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.