×

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.

With Service Binding Operator, you can:

  • Bind your workloads together with Operator-managed backing 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.

The custom resource definition (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.

Support matrix

Some features in the following table are in Technology Preview. These experimental features are not intended for production use.

In the table, features are marked with the following statuses:

  • TP: Technology Preview

  • GA: General Availability

Note the following scope of support on the Red Hat Customer Portal for these features:

Table 1. Support matrix
Service Binding Operator API Group and Support Status OpenShift Versions

Version

binding.operators.coreos.com

servicebinding.io

1.3.1

GA

GA

4.9-4.11

1.3

GA

GA

4.9-4.11

1.2

GA

GA

4.7-4.11

1.1.1

GA

TP

4.7-4.10

1.1

GA

TP

4.7-4.10

1.0.1

GA

TP

4.7-4.9

1.0

GA

TP

4.7-4.9

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see Red Hat CTO Chris Wright’s message.

Release notes for Service Binding Operator 1.3.1

Service Binding Operator 1.3.1 is now available on OpenShift Container Platform 4.9, 4.10, and 4.11.

Fixed issues

  • Before this update, a security vulnerability CVE-2022-32149 was noted for Service Binding Operator. This update fixes the CVE-2022-32149 error and updates the golang.org/x/text package from v0.3.7 to v0.3.8. APPSVC-1220

Release notes for Service Binding Operator 1.3

Service Binding Operator 1.3 is now available on OpenShift Container Platform 4.9, 4.10, and 4.11.

Removed functionality

  • In Service Binding Operator 1.3, the Operator Lifecycle Manager (OLM) descriptor feature has been removed to improve resource utilization. As an alternative to OLM descriptors, you can use CRD annotations to declare binding data.

Release notes for Service Binding Operator 1.2

Service Binding Operator 1.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, 4.10, and 4.11.

New features

This section highlights what is new in Service Binding Operator 1.2:

  • Enable Service Binding Operator to consider optional fields in the annotations by setting the optional flag value to true.

  • Support for servicebinding.io/v1beta1 resources.

  • Improvements to the discoverability of bindable services by exposing the relevant binding secret without requiring a workload to be present.

Known issues

  • Currently, when you install Service Binding Operator on OpenShift Container Platform 4.11, the memory footprint of Service Binding Operator increases beyond expected limits. With low usage, however, the memory footprint stays within the expected ranges of your environment or scenarios. In comparison with OpenShift Container Platform 4.10, under stress, both the average and maximum memory footprint increase considerably. This issue is evident in the previous versions of Service Binding Operator as well. There is currently no workaround for this issue. APPSVC-1200

  • By default, the projected files get their permissions set to 0644. Service Binding Operator cannot set specific permissions due to a bug in Kubernetes that causes issues if the service expects specific permissions such as, 0600. As a workaround, you can modify the code of the program or the application that is running inside a workload resource to copy the file to the /tmp directory and set the appropriate permissions. APPSVC-1127

  • There is currently a known issue with installing Service Binding Operator in a single namespace installation mode. The absence of an appropriate namespace-scoped role-based access control (RBAC) rule prevents the successful binding of an application to a few known Operator-backed services that the Service Binding Operator can automatically detect and bind to. When this happens, it generates an error message similar to the following example:

    Example error message
    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`

    Workaround 1: Install the Service Binding Operator in the all namespaces installation mode. As a result, the appropriate cluster-scoped RBAC rule now exists and the binding succeeds.

    Workaround 2: If you cannot install the Service Binding Operator in the all namespaces installation mode, install the following role binding into the namespace where the Service Binding Operator is installed:

    Example: Role binding for Crunchy Postgres Operator
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: service-binding-crunchy-postgres-viewer
    subjects:
      - kind: ServiceAccount
        name: service-binding-operator
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: service-binding-crunchy-postgres-viewer-role
  • According to the specification, when you change the ClusterWorkloadResourceMapping resources, Service Binding Operator must use the previous version of the ClusterWorkloadResourceMapping resource to remove the binding data that was being projected until now. Currently, when you change the ClusterWorkloadResourceMapping resources, the Service Binding Operator uses the latest version of the ClusterWorkloadResourceMapping resource to remove the binding data. As a result, {the servicebinding-title} might remove the binding data incorrectly. As a workaround, perform the following steps:

    1. Delete any ServiceBinding resources that use the corresponding ClusterWorkloadResourceMapping resource.

    2. Modify the ClusterWorkloadResourceMapping resource.

    3. Re-apply the ServiceBinding resources that you previously removed in step 1.

Release notes for Service Binding Operator 1.1.1

Service Binding Operator 1.1.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

Fixed issues

  • Before this update, a security vulnerability CVE-2021-38561 was noted for Service Binding Operator Helm chart. This update fixes the CVE-2021-38561 error and updates the golang.org/x/text package from v0.3.6 to v0.3.7. APPSVC-1124

  • Before this update, users of the Developer Sandbox did not have sufficient permissions to read ClusterWorkloadResourceMapping resources. As a result, Service Binding Operator prevented all service bindings from being successful. With this update, the Service Binding Operator now includes the appropriate role-based access control (RBAC) rules for any authenticated subject including the Developer Sandbox users. These RBAC rules allow the Service Binding Operator to get, list, and watch the ClusterWorkloadResourceMapping resources for the Developer Sandbox users and to process service bindings successfully. APPSVC-1135

Known issues

  • There is currently a known issue with installing Service Binding Operator in a single namespace installation mode. The absence of an appropriate namespace-scoped role-based access control (RBAC) rule prevents the successful binding of an application to a few known Operator-backed services that the Service Binding Operator can automatically detect and bind to. When this happens, it generates an error message similar to the following example:

    Example error message
    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`

    Workaround 1: Install the Service Binding Operator in the all namespaces installation mode. As a result, the appropriate cluster-scoped RBAC rule now exists and the binding succeeds.

    Workaround 2: If you cannot install the Service Binding Operator in the all namespaces installation mode, install the following role binding into the namespace where the Service Binding Operator is installed:

    Example: Role binding for Crunchy Postgres Operator
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: service-binding-crunchy-postgres-viewer
    subjects:
      - kind: ServiceAccount
        name: service-binding-operator
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: service-binding-crunchy-postgres-viewer-role
  • Currently, when you modify the ClusterWorkloadResourceMapping resources, the Service Binding Operator does not implement correct behavior. As a workaround, perform the following steps:

    1. Delete any ServiceBinding resources that use the corresponding ClusterWorkloadResourceMapping resource.

    2. Modify the ClusterWorkloadResourceMapping resource.

    3. Re-apply the ServiceBinding resources that you previously removed in step 1.

Release notes for Service Binding Operator 1.1

Service Binding Operator is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

New features

This section highlights what is new in Service Binding Operator 1.1:

  • Service Binding Options

    • Workload resource mapping: Define exactly where binding data needs to be projected for the secondary workloads.

    • Bind new workloads using a label selector.

Fixed issues

  • Before this update, service bindings that used label selectors to pick up workloads did not project service binding data into the new workloads that matched the given label selectors. As a result, the Service Binding Operator could not periodically bind such new workloads. With this update, service bindings now project service binding data into the new workloads that match the given label selector. The Service Binding Operator now periodically attempts to find and bind such new workloads. APPSVC-1083

Known issues

  • There is currently a known issue with installing Service Binding Operator in a single namespace installation mode. The absence of an appropriate namespace-scoped role-based access control (RBAC) rule prevents the successful binding of an application to a few known Operator-backed services that the Service Binding Operator can automatically detect and bind to. When this happens, it generates an error message similar to the following example:

    Example error message
    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`