Be aware however, that it can be configured with two different CRDs
The first one is the CRD according to the specification. The latter provides a few additional features that are quite convenient, but are not part of the standard specification.
In order to be compliant with the recommended way of exposing information, according to the specifications, a backing service has to fit the Provisioned Service schema. To do so, it declares its secret in the .status.binding field of its yaml. At this point only few CRDs one might come across support this, making the use relatively unlikely. Until adoption of the standard has become more widespread, a good alternative is provided via the use of annotations. A backing service can reference sources for the binding information it wishes to provide in its metadata. This is possible due to the Red Hat Service Binding Operator’s implementation of the Secret Generation Extension of the Service Binding specification.
Finally, there is the option of just directly referencing an existing Kubernetes Secret instead of a backing service inside the ServiceBinding. The benefit of not having to know the location of secret information, which is one of the major advantages of the specification in the first place, is lost this way. However, there is still some added flexibility and modularity with this method which makes it worth considering.