redhat-developer/service-binding-operator v0.10.0

on GitHub

This release delivers two security-related improvements that might break user experience. in certain environments.

• Service account used by the operator pod requires a way less permissions than before. Prior to this change, the service account
  had all rights to all APIs, even those deployed by 3rd-party operators. With the work in #1002, the service account rights are reduced significantly, so that the operator gets installed with the following permissions:
  • read/modify for deployments, deamonsets, replicasets, and statefulsets
  • read for pods, confgimaps, endpoints, services, crds, and csvs
  • read/modify/create for secrets and servicebindings

In order to enable the operator to perform binding to custom service resource, an additional cluster role must be added to the cluster. For example, if an operator manages backends.foo.com resources, then the following cluster role enables the operator to access them and read the available bindings:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: backends-view
  labels:
    service.binding/controller: "true"
rules:
  - apiGroups:
      - foo.com
    resources:
      - backends
    verbs:
      - get
      - list

service.binding/controller: "true" label is mandatory, so that the aggregated cluster role associated to the service account can pick it up.

• The operator now checks if service binding submitter has rights to read service and modify application resource. Without having the proper rights, binding requests are going to fail. Prior to merging #784, malicious users could create service bindings against services they do not have rights to talk to, and get access to them. Also they could injecting malicious services into applications.

In order to allow a user to perform service bindings, cluster role bindings or role bindings needs to be associated to that user, allowing:

• reading service resources
• modifying application resource

Improvements

• #1002 - Adjusted access for resources and apiversions (@bamachrn)
• #784 - Bind only if user submitting request can read services and update application resource (@pedjak)
• #1020 - Apply CSV best practices (@pedjak)
• #1018 - Set default operator channel to 'candidate' (@pedjak)
• #1012 - Fix markdown format in User_Guide.md (@dgolovin)
• #1009 - Set display name for spec CRD (@baijum)
• #1008 - Improve documentation used by 'kubectl explain' (@sadlerap)
• #999 - Add v1alpha2 CRD meta-data into CSV (@pmacik)

Bugfixes

• #1015 - Fix crash when annotation's sourceValue is invalid (@sadlerap)

Testing/CI

• #1010 - [acceptance-tests] Update CRD api version to v1 to support OpenShift v4.9 (@pmacik)
• #1011 - Include cluster-wide resources to be collected by GH Actions. (@pmacik)

Check OperatorHub page for installation instructions. Alternatively, you can install the operator by applying the published release.yaml file. If not installed through OLM, the operator requires that cert-manager is available on the cluster. It can be installed by:

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager.yaml

after that install the operator:

kubectl apply -f https://github.com/redhat-developer/service-binding-operator/releases/download/v0.10.0/release.yaml

The operator will be deployed in service-binding-operator namespace.