Chapter 6. Connecting applications to services

• Before this update, a security vulnerability CVE-2022-41717 was noted for Service Binding Operator. This update fixes the CVE-2022-41717 error and updates the golang.org/x/net package from v0.0.0-20220906165146-f3363e06e74c to v0.4.0. APPSVC-1256
• Before this update, Provisioned Services were only detected if the respective resource had the "servicebinding.io/provisioned-service: true" annotation set while other Provisioned Services were missed. With this update, the detection mechanism identifies all Provisioned Services correctly based on the "status.binding.name" attribute. APPSVC-1204

• 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

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

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

• 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

  APPSVC-1062

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

  APPSVC-1102

• 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

• 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

  APPSVC-1062

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

  APPSVC-1102

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

• 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

• 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

  APPSVC-1062

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

  APPSVC-1102

• TP: Technology Preview
• GA: General Availability

• Before this update, binding the data values from a Cluster custom resource (CR) of the postgresql.k8s.enterpriesedb.io/v1 API collected the host binding value from the .metadata.name field of the CR. The collected binding value is an incorrect hostname and the correct hostname is available at the .status.writeService field. With this update, the annotations that the Service Binding Operator uses to expose the binding data values from the backing service CR are now modified to collect the host binding value from the .status.writeService field. The Service Binding Operator uses these modified annotations to project the correct hostname in the host and provider bindings. APPSVC-1040
• Before this update, when you would bind a PostgresCluster CR of the postgres-operator.crunchydata.com/v1beta1 API, the binding data values did not include the values for the database certificates. As a result, the application failed to connect to the database. With this update, modifications to the annotations that the Service Binding Operator uses to expose the binding data from the backing service CR now include the database certificates. The Service Binding Operator uses these modified annotations to project the correct ca.crt, tls.crt, and tls.key certificate files. APPSVC-1045
• Before this update, when you would bind a PerconaXtraDBCluster custom resource (CR) of the pxc.percona.com API, the binding data values did not include the port and database values. These binding values along with the others already projected are necessary for an application to successfully connect to the database service. With this update, the annotations that the Service Binding Operator uses to expose the binding data values from the backing service CR are now modified to project the additional port and database binding values. The Service Binding Operator uses these modified annotations to project the complete set of binding values that the application can use to successfully connect to the database service. APPSVC-1073

• Currently, when you install the Service Binding Operator in the 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. In addition, the following error message is generated:

  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

  APPSVC-1062

• TP: Technology Preview
• GA: General Availability

• IBM Power Systems
• IBM Z and LinuxONE

• Exposal of binding data from services

  • Based on annotations present in CRD, custom resources (CRs), or resources.
  • Based on descriptors present in Operator Lifecycle Manager (OLM) descriptors.
  • Support for provisioned services

• 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.
  • Auto-detection of the binding data from resources owned by the backing service CR.
  • Compose custom binding data from the exposed binding data.
  • Support for non-PodSpec compliant workload resources.

• Security

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

• Service Binding with the binding.operators.coreos.com API group.
• Service Binding (Spec API) with the servicebinding.io API group.

• Bind your workloads to Operator-managed backing services.
• Automate configuration of binding data.
• 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.

• .name: Refers to the binding name exposed by the backing service. In the previous example, the binding names are HOST and PORT.
• .service.kind: Refers to the kind of service resource whose binding names are changed with the naming strategy.
• upper: String function used to post-process the character string while compiling the Go template string.
• POSTGRESQL: Prefix of the custom binding name.
• ENV: Suffix of the custom binding name.

• The backing service does not expose binding data.
• The values exposed are not available in the required format as expected by the workload.

Procedure

• Configure the spec.containers path by specifying a value in the ServiceBinding CR and bind this path to a spec.application.bindingPath.containersPath custom location:

  Example: ServiceBinding CR with the spec.containers path in a custom location

  apiVersion: binding.operators.coreos.com/v1alpha1
  kind: ServiceBinding
  metadata:
      name: spring-petclinic-pgcluster
  spec:
      services:
      - group: postgres-operator.crunchydata.com
        version: v1beta1
        kind: PostgresCluster
        name: hippo
        id: postgresDB
      - group: ""
        version: v1
        kind: Secret
        name: hippo-pguser-hippo
        id: postgresSecret
      application: 1
        name: spring-petclinic
        group: apps
        version: v1
        resource: deployments
      application: 2
        name: secondary-workload
        group: operator.sbo.com
        version: v1
        resource: secondaryworkloads
        bindingPath:
          containersPath: spec.containers 3

  1

  The sample application that points to a Deployment or any other similar resource with an embedded PodSpec.

  2

  The secondary workload, which is not compliant with the PodSpec.

  3

  The custom location of the container path.

Procedure

• Configure the spec.secret path by specifying a value in the ServiceBinding CR and bind this path at a spec.application.bindingPath.secretPath custom location:

  Example: ServiceBinding CR with the spec.secret path in a custom location

  apiVersion: binding.operators.coreos.com/v1alpha1
  kind: ServiceBinding
  metadata:
      name: spring-petclinic-pgcluster
  spec:
  ...
      application: 1
        name: secondary-workload
        group: operator.sbo.com
        version: v1
        resource: secondaryworkloads
        bindingPath:
          secretPath: spec.secret 2
  ...

  1

  The secondary workload, which is not compliant with the PodSpec.

  2

  The custom location of the secret path that contains the name of the Secret resource.

• If a ServiceBinding resource with the bindAsFiles: false flag value is created together with one of these mappings, then environment variables are projected into the .envFrom field underneath each path field specified in the corresponding ClusterWorkloadResourceMapping resource.

• As a cluster administrator, you can specify both a ClusterWorkloadResourceMapping resource and the .spec.application.bindingPath.containersPath field in a ServiceBinding.bindings.coreos.com resource for binding purposes.

  The Service Binding Operator attempts to project binding data into the locations specified in both a ClusterWorkloadResourceMapping resource and the .spec.application.bindingPath.containersPath field. This behavior is equivalent to adding a container entry to the corresponding ClusterWorkloadResourceMapping resource with the path: $containersPath attribute, with all other values taking their default value.