Deprecation Notice

As of February 2024, Service Binding Operator has been deprecated. No further feature development is expected at this time. Security-related releases may happen on an as-need basis, but no schedule for them can be guaranteed.

Usage of this project for new deployments is no longer recommended, and existing uses of this project are recommended to transition to a new solution.

Introduction

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 ServiceBinding resource.

service-binding-intro

Terminology
Service binding

The representation of the action of providing information about a service to a workload. Examples include establishing the exchange of credentials between a Java application and a database that it requires.

Backing service

Any service or software that the application consumes over the network as part of its normal operation. Examples include a database, a message broker, an application with REST endpoints, an event stream, an Application Performance Monitor (APM), or a Hardware Security Module (HSM).

Workload (application)

Any process, running within a container. Examples include a Spring Boot application, a NodeJS Express application, or a Ruby on Rails application.

This is different than an umbrella application as defined by the Kubernetes SIG, which refers to a set of micro-services.
Binding data

Information about a service that you use to configure the behavior of other resources within the cluster. Examples include credentials, connection details, volume mounts, or secrets.

Binding connection

Any connection that establishes an interaction between the connected components such as a bindable backing service and an application requiring that backing service.

Why service bindings?

Application developers need access to backing services to build and connect workloads. Today in Kubernetes, the exposure of secrets for connecting workloads to external services such as REST APIs, databases, event buses, and many more is manual and custom-made. Connecting workloads to backing services is always a challenge because each service provider suggests a different way to access their secrets, and each application developer consumes those secrets in a custom way to their workloads. While there is a good deal of value to this flexibility level, large development teams lose overall velocity dealing with each unique solution. In addition, manual configuration and maintenance of this binding together of workloads and backing services make the process tedious, inefficient, and error-prone.

With Service Binding Operator, you can:

  • Bind your workloads to backing services or external services.

  • Automate configuration of binding data.

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

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

Features

Exposal of binding data from services

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

  • Project secrets and services following the Provisioned Service standard.

Workload projection

  • Projection of binding data as files, with a volume mount.

  • 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.

  • Auto-detection of the binding data from resources owned by the backing service CR.

  • Change the binding names before projecting them into workload.

  • Compose custom binding data from the exposed binding data.

  • Support for non-PodSpec compliant workload resources.

Security

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

Understanding Service Binding Operator

The Service Binding Operator enables application developers to easily bind workloads together with 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.

Making an Operator-managed backing service bindable

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 Service Binding 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.

    This API is compliant with the Service Binding specification. It is fully supported and considered as the mature API. Use this API in production environments.

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

    This API is defined in the Service Binding specification. The specification is still evolving and maturing. As a result, the API might change in the future. Use the API carefully for testing purposes and preparing your integration to become fully compliant with the specification. The API is available in Service Binding Operator 1.x, as Tech Preview.

We will consider supporting only the servicebinding.io API group from the specification, after the Service Binding specification will be officially GA. Any resulting breaking changes will be handled safely.

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

Referenced specification

Service Binding Operator supports the Service Binding Specification for Kubernetes.