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 at this time. This repository will be archived at a future date.

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. We recommend using the reference implementation of service bindings, which can be found here.

The developers would like to express their sincere gratitude to everyone who has contributed over the last few years.

The Service Binding Operator

Connecting Applications with Services on Kubernetes and OpenShift

Introduction

Service Binding manages the data plane for applications and backing services. Service Binding Operator reads data made available by the control plane of backing services and projects the data to applications according to the rules provided via ServiceBinding resource.

Why Service Bindings?

Today in Kubernetes, the exposure of secrets for connecting applications to external services such as REST APIs, databases, event buses, and many more is manual and bespoke. Each service provider suggests a different way to access their secrets, and each application developer consumes those secrets in a custom way to their applications. While there is a good deal of value to this flexibility level, large development teams lose overall velocity dealing with each unique solution.

Service Binding:

• Enables developers to connect their application to backing services with a consistent and predictable experience
• Removes error-prone manual configuration of binding information
• Provides service operators a low-touch administrative experience to provision and manage access to services
• Enriches development lifecycle with a consistent and declarative service binding method that eliminates environments discrepancies

Key Features

• Support Binding with backing services represented by Kubernetes resources including third-party CRD-backed resources.
• Support binding with multiple-backing services.
• Extract binding information based on annotations present in CRDs/CRs/resources.
• Extract binding values based on annotations present in OLM descriptors.
• Project binding values as volume mounts.
• Project binding values as environment variables.
• Binding of PodSpec-based workloads.
• Binding of non-PodSpec-based Kubernetes resources.
• Custom binding variables composed from one or more backing services.
• Auto-detect binding resources in the absence of binding decorators.

Service Binding Specification Alignment

• Service Binding Operator provides two different APIs.
  • binding.operators.coreos.com/v1alpha1: This API is compliant with the Service Binding Specification for Kubernetes.
  • servicebinding.io/v1alpha3 (tech preview): This API implements the Service Binding Specification for Kubernetes.

The Service Binding Specification for Kubernetes is still evolving and maturing. We are tracking changes to the spec as it approaches a stable release and are updating our APIs accordingly and as a result our APIs may change in the future.

Getting started

Installing in a Cluster

Follow OperatorHub instructions.

Usage

To get started, consult the quick start tutorial. General documentation can be found here.

Read more

Here are some more places to read about SBO in use:

• Announcing Service Binding Operator 1.0 GA
• How to use service binding with RabbitMQ
• Bind workloads to services easily with the Service Binding Operator and Red Hat OpenShift
• Drag&Drop JAR and Service Binding
• Bind a Kafka cluster to a Node.js application the easy way

Known bindable operators

The Service Binding Operator can automatically detect and bind to services created by a limited selection of operators. These operators do not support binding directly. Instead, the service binding operator is able to detect and configure the operator's CRDs so that they become bindable. The long-term intention is to contribute upstream support for service binding and remove the operators that gain native support for service bindings. The operators that currently fall in this category are:

• OpsTree Redis: bindable with Redis.redis.redis.opstreelabs.in/v1beta1 services
• CrunchyData Postgres: bindable with PostgresCluster.postgres-operator.crunchydata.com/v1beta1 services
• Cloud Native PostgreSQL: bindable with Cluster.postgresql.k8s.enterprisedb.io/v1 services
• Percona XtraDB Cluster: bindable with PerconaXtraDBCluster.pxc.percona.com/v1-8-0 and v1-9-0 services
• Percona MongoDB: bindable with PerconaServerMongoDB.psmdb.percona.com/v1-9-0, v1-10-0 and v1 services
  • NOTE: Provides administrative access to the cluster by default
• RabbitMQ Cluster: bindable with RabbitmqCluster.rabbitmq.com/v1beta1 services

OpenShift Streams for Apache Kafka are also bindable, although getting binding to work requires a little more effort. See here for more details.

Roadmap

The direction of this project is tracked under milestones posted here on GitHub.

Community, discussion, contribution, and support

The Service Binding community meets bi-weekly on Thursdays at 1:00 PM UTC via Google Meet, and the meeting agenda is maintained here. If you have a topic you wish to discuss at this meeting, please feel free to add a discussion topic to the agenda.

Please file bug reports on Github. For any other questions, reach out on service-binding-support@redhat.com.

Join the service-binding-operator channel in the Kubernetes Workspace for any discussions and collaboration with the community.