Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Introducing the Service Binding Operator

December 19, 2019
Shoubhik Bose Steve Speicher Len DiMaggio
Related topics:
JavaKubernetesNode.jsOperators
Related products:
Red Hat OpenShift

Share:

    Connecting applications to the services that support them—for example, establishing the exchange of credentials between a Java application and a database that it requires—is referred to as binding. The configuration and maintenance of this binding together of applications and backing services can be a tedious and inefficient process. Manually editing YAML files to define binding information is error-prone and can introduce difficult-to-debug failures.

    Note: Service Binding Operator has changed significantly since this article was published and the information is now out of date. Please read How to use service binding with RabbitMQ for the latest information about this technology.

    Introduction to service binding

    The goal of the Service Binding Operator is to solve this binding problem. By making it easier for application developers to bind applications with needed backing services, the Service Binding Operator also assists operator providers in promoting and expanding the adoption of their operators. This article introduces the Service Binding Operator and describes how it functions. In the next article, we'll demonstrate its use through a real-world example.

    The case for managed binding

    The Service Binding Operator enables applications to use external services by automatically collecting and sharing binding information (credentials, connection details, volume mounts, secrets, etc.) with the application. In effect, the Service Binding Operator defines a contract between a "bindable" backing service (for example, a database operator) and an application requiring that backing service.

    Note that in addition to the initial sharing of binding information, the binding is also "managed" by the Service Binding Operator. This statement means that, if credentials or URLs undergo modification by the backing service operator, those changes are automatically reflected in the application.

    There are two parts to this contract. The first part concerns making the backing service bindable and the second part concerns binding the application and the service together. Both parts are supported by a new custom resource, the ServiceBindingRequest.

    The ServiceBindingRequest custom resource

    The Service Binding Operator enables application developers to more easily bind applications together with operator-managed backing services (such as a database) without having to perform manual configuration of secrets, ConfigMaps, etc. The Service Binding Operator accomplishes this task by automatically collecting binding information and sharing it with an application and an operator-managed backing service. This binding is performed through a new custom resource called a ServiceBindingRequest.

    apiVersion: apps.openshift.io/v1alpha1
    kind: ServiceBindingRequest
    metadata:
      name: binding-request
      namespace: service-binding-demo
    spec:
      applicationSelector:
        resourceRef: nodejs-rest-http-crud
        group: apps
        version: v1
        resource: deployments
      backingServiceSelector:
        group: postgresql.baiju.dev
        version: v1alpha1
        kind: Database
        resourceRef: db-demo
    ServiceBindingRequest

    Figure 1: The selectors in a ServiceBindingRequest.">

    A ServiceBindingRequest includes the following two selectors. The first is the applicationSelector, which identifies the application to be bound with the backing service. The ResourceRef defined here marks an application for binding. The second is the backingServiceSelector, which identifies the backing service with which applications will be bound, as shown in Figure 1:

    Additional data in the ServiceBindingRequest can contain a combination of sensitive information such as usernames and passwords, plus non-sensitive information such as port numbers. In order to configure an existing operator to be bindable, an operator provider has to add a ServiceBindingRequest descriptor to the operator’s manifest. The statusDescriptors in that manifest will contain the information needed by the Service Binding Operator to bind the application together with the backing service operator.

    Note: Sample backing service operators that are already bindable are available here.

    Figure 2 illustrates the relationship between the ServiceBindingRequest, its selectors, the application being bound, and the backing service. Note that for the applicationSelector, the relevant attributes are the application’s group, version, resource, and resourceRef, and that for the backingServiceSelector, the relevant attributes are the version, kind, and resourceRef:

    The relationship between the ServiceBindingRequest and related components.
    Figure 2: The relationship between the ServiceBindingRequest and related components.

    Making an operator-managed backing service bindable

    To make a service bindable, the operator provider needs to express the information needed by applications to bind with the services provided by the operator. In other words, the operator provider must express the information that is interesting to applications.

    The binding information is provided as annotations in the Custom Resource Definition (CRD) of the operator that manages the backing service. The Service Binding Operator extracts the annotations to bind the application together with the backing service.

    For example, Figure 3 shows a bind-able operator's annotations in its CRD for a PostgreSQL database backing operator. Note the highlighted text and that status.dbConfigMap is a ConfigMap where the username and password are interesting for binding:

    A bindable operator's CRD annotations.
    Figure 3: A bindable operator's CRD annotations.

    An alternate method for making a service bindable enables operators that manage backing services, but which do not have any metadata in their CSV to use the Service Binding Operator to bind together the service and applications. The Service Binding Operator binds all sub-resources defined in the backing service CR by populating the binding secret with information from the routes, services, ConfigMaps, and secrets owned by the backing service CR.

    Note: This is how resource and sub-resource relationships are set in Kubernetes.

    The binding itself is initiated by the introduction of the API option in the backing service CR (as shown in Figure 4):

    Binding initiation.
    Figure 4: Binding initiation.

    When this API option is set to true, the Service Binding Operator automatically detects the routes, services, ConfigMaps, and secrets owned by the backing service CR.

    Binding an application together with a backing service

    Manually binding an application together with a backing service without the Service Binding Operator is a time-consuming and error-prone process. The steps needed to perform the binding include:

    1. Locating the binding information in the backing service’s resources.
    2. Creating and referencing any necessary secrets.
    3. Manually editing the application’s DeploymentConfig, Deployment, Replicaset, KnativeService, or anything else that uses a standard PodSpec to reference the binding request.

    In contrast, by using the Service Binding Operator, the only action that an application developer must make during the import of the application is to make clear the intent that the binding must be performed. This task is accomplished by creating the ServiceBindingRequest. The Service Binding Operator takes that intent and performs the binding on behalf of the application developer.

    In summary, there are two steps that an application developer must perform. First, they must signal the intent to bind the application to the backing service by adding labels to the application. Second, they must create a new ServiceBindingRequest that references the backing service.

    When the ServiceBindingRequest is created, the Service Binding Operator's controller collects the binding information into an intermediary secret, which it shares with the application through environment variables.

    Note that an optional approach that can be used to provide binding information is through custom environment variables. We'll provide more on this topic, along with a real-world example, in the next article.

    Resources

    • The Service Binding Operator GitHub repo.
    • A set of examples, each of which illustrates a usage scenario for the Service Binding Operator, is being developed in parallel with the Operator. Each example includes documentation and can be run either through the OpenShift web console or command-line client.
    • Sample Backing Service Operators are available here.
    Last updated: November 5, 2021

    Recent Posts

    • Expand Model-as-a-Service for secure enterprise AI

    • OpenShift LACP bonding performance expectations

    • Build container images in CI/CD with Tekton and Buildpacks

    • How to deploy OpenShift AI & Service Mesh 3 on one cluster

    • JVM tuning for Red Hat Data Grid on Red Hat OpenShift 4

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue