This topic provides API documentation for Role-Based Access Control (RBAC) relating to Services Toolkit’s APIs.
This section describes the following Aggregation labels:
Use this label to grant the Services Toolkit and service bindings controllers permission to get, list, and watch resources to be claimed and bound in the cluster.
For example, the following ClusterRole
grants the controllers permission to get, list, and watch RabbitmqCluster
resources. You cannot create ClassClaims
or ResourceClaims
unless the controllers have at least these permissions for each resource type being claimed.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: resource-claims-rmq-role
labels:
servicebinding.io/controller: "true"
rules:
- apiGroups:
- rabbitmq.com
resources:
- rabbitmqclusters
verbs:
- get
- list
- watch
Use this label to aggregate RBAC rules to provider-kubernetes
, which is a Crossplane Provider
installed by default as part of the Crossplane package in Tanzu Application Platform. You must grant relevant RBAC permissions for each API Group/Kind used during the creation of Compositions
as part of setting up dynamic provisioning.
For example, the following ClusterRole
grants provider-kubernetes
full control over rabbitmqclusters
on the rabbitmq.com
API Group. This allows you to compose rabbitmqclusters
in Compositions
. For a full example, see Setup Dynamic Provisioning of Service Instances.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: rmqcluster-read-writer
labels:
services.tanzu.vmware.com/aggregate-to-provider-kubernetes: "true"
rules:
- apiGroups:
- rabbitmq.com
resources:
- rabbitmqclusters
verbs:
- "*"
Use this label to aggregate RBAC rules to provider-helm
, which is a Crossplane Provider
installed by default as part of the Crossplane package in Tanzu Application Platform. You must grant relevant RBAC permissions for each API Group/Kind used during the creation of Helm releases when using the Release
managed resource as part of Compositions
.
For example, the following ClusterRole
grants provider-helm
full control over rabbitmqclusters
on the rabbitmq.com
API Group. This allows you to compose Helm Releases
which themselves eventually deploy rabbitmqclusters
in your Compositions
.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: rmqcluster-read-writer
labels:
services.tanzu.vmware.com/aggregate-to-provider-helm: "true"
rules:
- apiGroups:
- rabbitmq.com
resources:
- rabbitmqclusters
verbs:
- "*"
Services Toolkit supports using the claim
verb for RBAC rules that apply to a ClusterInstanceClass
. You can use this with relevant aggregating labels or ClusterRoleBindings
as a form of access control to specify who can claim from which ClusterInstanceClass
.
For example:
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: app-operator-claim-class-bigcorp-rabbitmq
labels:
# (Optional) Aggregates this ClusterRole to Tanzu Application Platform's
# app-operator user role at the cluster scope. You can choose to aggregate
# this to any of the other standard user roles as well.
apps.tanzu.vmware.com/aggregate-to-app-operator-cluster-access: "true"
rules:
# Permits claiming from the 'bigcorp-rabbitmq' class
- apiGroups:
- services.apps.tanzu.vmware.com
resources:
- clusterinstanceclasses
resourceNames:
- bigcorp-rabbitmq
verbs:
- claim
As of Services Toolkit v0.12.0 in Tanzu Application Platform v1.7.0, you must grant the permission to claim
from a ClusterInstanceClass
at the cluster level. You now must use a ClusterRole
and ClusterRoleBinding
. Namespace-scoped permissions, such as using a Role
and RoleBinding
or ClusterRole
and RoleBinding
, are not sufficient. If you used Roles
and RoleBindings
, or ClusterRoles
and RoleBindings
to grant claim
permissions in specific namespaces only, this change might affect you. For more information, see Authorize users and groups to claim from provisioner-based classes.
Previously, Services Toolkit allowed you to claim
from a ClusterInstanceClass
with only namespace-level permissions. However, this allowed users with only namespace-level permissions to obtain or indirectly deploy resources into namespaces that they do not have access to according to the RBAC permissions.