See the documentation on installing the latest release of the Services Toolkit to get started.
The main purpose of
ResourceClaim is to identify the concrete Kubernetes object within the cluster that satisfies the requirements stated in the claim.
Once the object is identified the status condition
ResourceMatched is set to true.
If the reference object adheres to the Provisioned Service duck type the
.status.binding.name will be copied to the
.status.binding.name and the
ResourceClaimed condition will be set to true. The claim object itself is a Provisioned Service, so it can be used to define a Service Binding.
At present the reference specified in
.spec.ref must be in the same namespace of the
ResourceClaim, in the near future we plan to allow cross-namespace referencing.
apiVersion: services.tanzu.vmware.com/v1alpha1 kind: ResourceClaim metadata: name: production-database namespace: accounts spec: ref: apiVersion: services.tanzu.vmware.com/v1alpha1 kind: PostgreSQL name: my-prod-db status: binding: name: production-database-secret # copied from Postgresql/my-prod-db conditions: - lastTransitionTime: "2019-10-22T16:29:25Z" status: "True" type: Ready - lastTransitionTime: "2019-10-22T16:29:24Z" status: "True" type: ResourceClaimed - lastTransitionTime: "2019-10-22T16:29:23Z" status: "True" type: ResourceMatched
ResourceClaim controller MUST have read access to Resources specified in the
ResourceClaim spec. As these resources are not known upfront, the appropriate RBAC must be setup on the Cluster. To accomplish this RBAC must be setup using Aggregated ClusterRoles with the
services.vmware.tanzu.com/aggregate-to-resource-claims: true label.
An example of a ClusterRole that allows
RabbitmqCluster resources to be read by the
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: resource-claims-rmq-role labels: services.vmware.tanzu.com/aggregate-to-resource-claims: "true" rules: - apiGroups: - rabbitmq.com resources: - rabbitmqclusters verbs: - get - list - watch