Introduction
Application developers need access to backing services to build and connect workloads. Connecting workloads to backing services is always a challenge because each service provider requires a different way to access their secrets and consume them in a workload.
The Service Binding Operator enables application developers to easily bind workloads together with operator-managed backing services, without any manual procedures to configure the binding connection. For the Service Binding Operator to provide the binding data, as an Operator provider or user who creates backing services, you must expose the binding data to be automatically detected by the Service Binding Operator. Then, the Service Binding Operator automatically collects the binding data from the backing service and shares it with a workload to provide a consistent and predictable experience.
Methods of exposing binding data
This section describes the methods you can use to expose the binding data.
Ensure that you know and understand your workload requirements and environment, and how it works with the provided services.
Binding data is exposed under the following circumstances:
-
Backing service is available as a provisioned service resource.
The service you intend to connect to is compliant with the Service Binding specification. You must create a
Secret
resource with all the required binding data values and reference it in the backing service custom resource (CR). The detection of all the binding data values is automatic. -
Backing service is not available as a provisioned service resource.
You must expose the binding data from the backing service. Depending on your workload requirements and environment, you can choose any of the following methods to expose the binding data:
Service Binding Operator implements support for Secret Generation Extension and hence provides the ability to expose the binding data values from the backing service resources and CRDs. You can use the following categories of binding data to map and expose the values:
-
A string from a resource
-
A constant value
-
An entire config map or secret that is referenced from a resource
-
A specific entry from a config map or secret that is referenced from a resource
-
A resource definition value
-
Entries of a collection of objects with the mapping keys and values from entries in a config map or secret that is referenced from a resource
-
A collection of specific entry values in a resource’s collection of objects
-
A value to a specific key
-
A value of a collection to a key with a generated name
Data model
This section explains the data model used in the annotations.
-
path
: JSONPath template is composed of JSONPath expressions enclosed by curly braces {}. The data model used in the annotations follow specific conventions.
Service binding annotations must use the following convention:
service.binding(/<NAME>)?:
"<VALUE>|(path=<JSONPATH_TEMPLATE>(,objectType=<OBJECT_TYPE>)?(,elementType=<ELEMENT_TYPE>)?(,sourceKey=<SOURCE_KEY>)?(,sourceValue=<SOURCE_VALUE>)?)"
where:
<NAME>
|
Specifies the name under which the binding value is to be exposed. You can exclude it only when the |
<VALUE>
|
Specifies the constant value exposed when no |
The data model provides the details on the allowed values and semantic for the path
, elementType
, objectType
, sourceKey
, and sourceValue
parameters.
Parameter | Description | Default value |
---|---|---|
|
JSONPath template that consists JSONPath expressions enclosed by curly braces {}. The behaviour matches kubectl JSONPath support. |
N/A |
|
Specifies whether the value of the element referenced in the
|
|
|
Specifies whether the value of the element indicated in the |
|
|
Specifies the key in the Note:
|
N/A |
|
Specifies the key in the slice of maps. Note:
|
N/A |
The |