Creating Service Binding

In this section, consider the case that the service you want to connect to is already exposing binding data by either:

  1. Provisioned Service

  2. Direct Secret Reference

  3. Secret Generated through CRD/CR annotations

  4. Secret Generated through OLM Descriptors

  5. Detect Bindings through owned resources

You also need an application to be used along with the ServiceBinding resource.

Service Binding Operator is providing and supporting two different APIs.

  • binding.operators.coreos.com/v1alpha1: This API is compliant with the Service Binding specification. It is fully supported and considered as the mature API. It’s the API we recommend in production environments.

  • servicebinding.io/v1alpha3 : This API is the one defined in the Service Binding specification. The specification is still evolving and maturing, as a result the API might change in the future. We recommend you to carefully use that API for testing purposes and preparing your integration to become fully compliant with the specification. It is available in Service Binding Operator 1.x, as Tech Preview.

We’ll consider supporting only the API from the specification, once the Service Binding specification will be officially GA. Of course, that will be a breaking change and handle in a safe way for you.

Some of the key difference between the APIs:

binding.operators.coreos.com API servicebinding.io API

Support naming strategy

Does not support naming strategy

Support custom mapping

Does not support custom mapping

Support to auto-detect binding resources

Does not support auto-detecting binding resources

Flag to bind as files or env vars

No flag switch between files and env vars
Service Binding Operator performs requests against Kubernetes API using a dedicated service account. By default the account has permissions to bind services to applications, both represented by standard Kubernetes Deployments, DaemonSets, ReplicaSets, StatefulSets and OpenShift DeploymentConfigs. Binding services/application defined by CRD requires adding appropriate rights to the service account, either by cluster admins or operator vendors. Please check RBAC Requirements Section for further details.

+ Equally important is to note that the Service Binding Operator prevent users to bind services to application if the user does not have permissions to read binding data or modify application resource. This check is added to prevent privilege escalation, i.e. get access to unauthorized services/applications.

Example servicebinding in binding.operators.coreos.com/v1alpha1 API:
apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    version: v1
    group: apps
    kind: Deployment
    name: online-banking
  services: (1)
  - version: v1alpha1 (2)
    group: example.com (3)
    kind: AccountService (4)
    name: prod-account-service (5)
1 is a list of resources related to a service
2 service API version
3 service API group
4 serivce kind
5 service name
Example with servicebinding.io API group:
apiVersion: servicebinding.io/v1alpha3
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application: (1)
    apiVersion: apps/v1
    kind: Deployment
    name: online-banking

  service:
    apiVersion: example.com/v1alpha1
    kind: AccountService
    name: prod-account-service
1 The application resource is a deployment resource with the name online-banking.