Declaring binding data through OLM descriptors

You can use this method if your backing service is provided by an Operator. If your Operator is distributed as an Operator Bundle, you can add Operator Lifecycle Manager (OLM) descriptors to describe the binding data that is to be exposed. The OLM descriptors are part of Cluster Service Version resources. The Service Binding Operator detects the OLM descriptors and then creates a Secret resource with the values extracted based on the detected OLM descriptors.

You can expose the binding data by using the specDescriptors array and statusDescriptors array. The specDescriptors array specifies a path under the .spec section of a CR. The statusDescriptors array specifies a path under the .status section of a CR.

Following are the only two fields that are used for binding the data:

  • Path: A dot-delimited path of the field on the object as described by the descriptor.

  • X-Descriptors: Defines the binding data.

The following examples show how to define an X-Descriptor depending on the resource to which you point the path:

Example: X-Descriptor definition for exposing a secret
- path: data.dbCredentials
  x-descriptors:
  - urn:alm:descriptor:io.kubernetes:Secret
  - service.binding
Example: X-Descriptor definition for exposing a config map
- path: data.dbConfiguration
  x-descriptors:
  - urn:alm:descriptor:io.kubernetes:ConfigMap
  - service.binding

  • You must have a service.binding entry in the X-Descriptors to identify that it is a configuration for service binding.

  • The absence of the Secret or ConfigMap specific X-Descriptors indicates that the descriptor is referencing the binding data value at the given path.

Exposing an entire config map or secret that is referenced from a resource

The following example shows how to expose an entire config map through OLM descriptors:

Example: Exposing an entire config map through OLM descriptors
- path: data.dbConfiguration
  x-descriptors:
  - urn:alm:descriptor:io.kubernetes:ConfigMap
  - service.binding

This example uses the path attribute with a urn:alm:descriptor:io.kubernetes:ConfigMap entry to indicate that the path points to the ConfigMap service resource.

If you intend to project all the values from a ConfigMap service resource, you must specify it as an attribute in the backing service CR. For example, if the attribute is part of the .spec section, you can create and use a specDescriptors array. Or, if the attribute is part of the .status section, you can create and use a statusDescriptors array.

Exposing a specific entry from a config map or secret that is referenced from a resource

The following examples show how to expose a specific entry from a config map or secret through OLM descriptors:

Example: Exposing an entry from a config map through OLM descriptors
- path: data.dbConfiguration
  x-descriptors:
  - urn:alm:descriptor:io.kubernetes:ConfigMap
  - service.binding:my_certificate:sourceKey=certificate
Example: Exposing an entry from a secret through OLM descriptors
- path: data.dbConfiguration
  x-descriptors:
  - urn:alm:descriptor:io.kubernetes:Secret
  - service.binding:my_certificate:sourceKey=certificate

The previous examples use the path attribute with an X-Descriptors update for service.binding and sourceKey by providing the following information:

  • Name of the binding key that is to be projected

  • Name of the key in the Secret service resource

Exposing a resource definition value

The following example shows how to expose a resource definition value through OLM descriptors:

Example: Exposing a resource definition value through OLM descriptors
- path: data.connectionURL
  x-descriptors:
  - service.binding:uri

The previous example uses the connectionURL attribute that points to the required resource definition value that is to be projected as uri.

If required values are available as attributes of backing service resources, annotating these values using X-Descriptors identifies them as the binding data.

Exposing entries of a collection with the key and value from each entry

The following example shows how to expose the entries of a collection with the key and value from each entry through OLM descriptors:

Example: Exposing the entries of a collection through OLM descriptors
- path: bootstrap
  x-descriptors:
  - service.binding:endpoints:elementType=sliceOfMaps:sourceKey=type:sourceValue=url

The previous example uses the path attribute with an X-Descriptors update for the required entries of a collection.

Example: Configuration from a backing service resource
status:
  connections:
    - type: primary
      url: primary.example.com
    - type: secondary
      url: secondary.example.com
    - type: '404'
      url: black-hole.example.com

The previous example helps you to project all those values with keys such as primary, secondary, and so on.

Exposing items of a collection with one key per item

The following example shows how to expose the items of a collection with one key per item through OLM descriptors:

Example: Exposing the items of a collection through OLM descriptors
- path: spec.tags
  x-descriptors:
  - service.binding:tags:elementType=sliceOfStrings

The previous example uses the path attribute with an X-Descriptors update for the required items of a collection.

Example: Configuration from a backing service resource
spec:
  tags:
  - knowledge
  - is
  - power

The previous example helps you project all those values with key such as prefix_0, prefix_1, and so on. The default prefix is the name of the resource kind:.

Exposing values of collection entries with one key per entry value

The following example shows how to expose the values of collection entries with one key per entry value through OLM descriptors:

Example: Exposing the values of collection entries through OLM descriptors
- path: bootstrap
  x-descriptors:
  - service.binding:endpoints:elementType=sliceOfStrings:sourceValue=url

The previous example uses the path attribute with an X-Descriptors update for the required values of a collection.

The following example shows how the previous values of a collection are projected into the bound application.

Example: Binding data files
/bindings/<binding-name>/url_0 => primary.example.com
/bindings/<binding-name>/url_1 => secondary.example.com
/bindings/<binding-name>/url_2 => black-hole.example.com

The previous example helps you project all those values with key such as prefix_0, prefix_1, and so on. The default prefix is the name of the resource kind:.