Understanding Service Binding Operator

    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.

    This section summarizes the basic terms used in Service Binding.

    The Service Binding Operator consists of a controller and an accompanying custom resource definition (CRD) for service binding. It manages the data plane for workloads and backing services. The Service Binding Controller reads the data made available by the control plane of backing services. Then, it projects this data to workloads according to the rules specified through the resource.

    As a result, the Service Binding Operator enables workloads to use backing services or external services by automatically collecting and sharing binding data with the workloads. The process involves making the backing service bindable and binding the workload and the service together.

    To make a service bindable, as an Operator provider, you need to expose the binding data required by workloads to bind with the services provided by the Operator. You can provide the binding data either as annotations or as descriptors in the CRD of the Operator that manages the backing service.

    Binding a workload together with a backing service

    By using the Service Binding Operator, as an application developer, you need to declare the intent of establishing a binding connection. You must create a ServiceBinding CR that references the backing service. This action triggers the Service Binding Operator to project the exposed binding data into the workload. The Service Binding Operator receives the declared intent and binds the workload together with the backing service.

    The CRD of the Service Binding Operator supports the following APIs:

    • Service Binding with the binding.operators.coreos.com API group.

    • Service Binding (Spec API) with the servicebinding.io API group.

    With Service Binding Operator, you can:

    • Bind your workloads to Operator-managed backing services.

    • Provide service operators with a low-touch administrative experience to provision and manage access to services.

    • Enrich the development lifecycle with a consistent and declarative service binding method that eliminates discrepancies in cluster environments.

    • Exposal of binding data from services

      • Based on annotations present in CRD, custom resources (CRs), or resources.
    • Workload projection

      • Projection of binding data as files, with volume mounts.

      • Projection of binding data as environment variables.

    • Service Binding Options

      • Bind backing services in a namespace that is different from the workload namespace.

      • Project binding data into the specific container workloads.

      • Compose custom binding data from the exposed binding data.

      • Support for non-PodSpec compliant workload resources.

    • Security

      • Support for role-based access control (RBAC).

    The CRD of the Service Binding Operator supports the following APIs:

    • Service Binding with the binding.operators.coreos.com API group.

    • Service Binding (Spec API) with the servicebinding.io API group.

    Both of these API groups have similar features, but they are not completely identical. Here is the complete list of differences between these API groups:

    FeatureSupported by the API groupSupported by the servicebinding.io API groupNotes

    Binding to provisioned services

    Yes

    Yes

    Not applicable (N/A)

    Direct secret projection

    Yes

    Yes

    Not applicable (N/A)

    Bind as files

    Yes

    Yes

    • Default behavior for the service bindings of the servicebinding.io API group

    • Opt-in functionality for the service bindings of the binding.operators.coreos.com API group

    Bind as environment variables

    Yes

    Yes

    • Default behavior for the service bindings of the binding.operators.coreos.com API group.

    • Opt-in functionality for the service bindings of the servicebinding.io API group: Environment variables are created alongside files.

    Selecting workload with a label selector

    Yes

    Not applicable (N/A)

    Detecting binding resources (.spec.detectBindingResources)

    Yes

    No

    The API group has no equivalent feature.

    Naming strategies

    Yes

    No

    There is no current mechanism within the servicebinding.io API group to interpret the templates that naming strategies use.

    Container path

    Yes

    Partial

    Because a service binding of the binding.operators.coreos.com API group can specify mapping behavior within the ServiceBinding resource, the servicebinding.io API group cannot fully support an equivalent behavior without more information about the workload.

    Container name filtering

    No

    Yes

    The binding.operators.coreos.com API group has no equivalent feature.

    Secret path

    Yes

    No

    The servicebinding.io API group has no equivalent feature.

    Alternative binding sources (for example, binding data from annotations)

    Yes

    Allowed by Service Binding Operator

    The specification requires support for getting binding data from provisioned services and secrets. However, a strict reading of the specification suggests that support for other binding data sources is allowed. Using this fact, Service Binding Operator can pull the binding data from various sources (for example, pulling binding data from annotations). Service Binding Operator supports these sources on both the API groups.