Binding Secret Generation Extensions

[baijum]

I propose to convert the "Binding Secret Generation Strategies'' extension to three extensions. The first one based on OLM x-descriptors, the second one based on custom resource definition annotations, and the third one based on custom resource annotations.

These extensions can follow the pattern of ProvisionedService duck type as described in issue #145.

apiVersion: mapping.service.binding/v1alpha2
kind: XDescriptorsSecretGenerator
spec:
  type: <optional-type-value>
  provider: <optional-provider-value>
  service:
    apiVersion: com.example/v1alpha1
    kind: AccountService
    name: prod-account-service
status:
  binding:
    name: <generated-secret-resource>

apiVersion: mapping.service.binding/v1alpha2
kind: CustomResourceDefinitionSecretGenerator
spec:
  type: <optional-type-value>
  provider: <optional-provider-value>
  service:
    apiVersion: com.example/v1alpha1
    kind: AccountService
    name: prod-account-service
status:
  binding:
    name: <generated-secret-resource>

apiVersion: mapping.service.binding/v1alpha2
kind: CustomResourceSecretGenerator
spec:
  type: <optional-type-value>
  provider: <optional-provider-value>
  service:
    apiVersion: com.example/v1alpha1
    kind: AccountService
    name: prod-account-service
status:
  binding:
    name: <generated-secret-resource>

Since these are ProvisionedService conforming resources, all the implementation of the core-spec will be compatible.

[DhritiShikhar]

@baijum What is the benefit of this proposal?

[baijum]

What is the benefit of this proposal?

The current extension expects the ServiceBinding reconciler to act upon the x-descriptors or annotations. That makes the extension tied to the implementation. With the proposed new extensions, the secret generation logic can be implemented by separate reconcilers. For example, if an organization wants to implement these extensions, it can easily integrate with the other existing implementations. This also makes it easy to mix and match core implementation and extensions. Please read issue #145 for more details.

[baijum]

If CRD proliferation is a concern, we could go for a single CRD with the .spec.category attribute.

apiVersion: mapping.service.binding/v1alpha2
kind: SecretGenerator
spec:
  category: <Xdescriptor | CustomResourceDefinition | CustomResource>
  type: <optional-type-value>
  provider: <optional-provider-value>
  service:
    apiVersion: com.example/v1alpha1
    kind: AccountService
    name: prod-account-service
status:
  binding:
    name: <generated-secret-resource>

[sbose78]

CRD proliferation

This is definitely a concern, I like what you've proposed to address this.

Question, who would be creating/providing this CR ?

• The one who connects the application to the service ( probably the application author ), Or
• The service provider would be shipping this SecretGenerator CR ?

[baijum]

The SecretGenerator custom resource will be created by the one who connects the application to the service. We can encourage service providers to document and/or give examples for the same.

[scothis]

Question, who would be creating/providing this CR ?

You can make a strong case for both parties. Either the app dev who needs to consume a service that wasn't fully compliant, or by a service provider who has a resource that isn't itself compliant, but still want to offer a compliant sibling resource.

I agree with @baijum that it will most often be "one who connects the application to the service", but unlike with the ServiceBinding resource it won't be exclusively that person.

[baijum]

The current implementation of Red Hat's Service Binding Operator merge CR annotation, CRD annotation, and X-Descriptors. As long as the order of precedence is well defined, I think we can avoid .spec.category. This behavior will be closer to the existing implementation. Since CR annotation has more precedence over CRD annotation, the person who connects the application to the service gets a chance to override what's there in the CRD annotation. Contrary to the current implementation, I think X-Descriptors should get precedence over CRD annotation. That will give those who package the original operator a chance to override what's there in the CRD annotation.

apiVersion: mapping.service.binding/v1alpha2
kind: SecretGenerator
spec:
  type: <optional-type-value>
  provider: <optional-provider-value>
  service:
    apiVersion: com.example/v1alpha1
    kind: AccountService
    name: prod-account-service
status:
  binding:
    name: <generated-secret-resource>

[baijum]

The SecretGenerator is going to be used with the ServiceBinding resource in tandem. And ServiceBinding resource has special attributes to override type and provider values. So, I think we can drop those two optional attributes from the SecretGenerator resource.

apiVersion: mapping.service.binding/v1alpha2
kind: SecretGenerator
spec:
  service:
    apiVersion: com.example/v1alpha1
    kind: AccountService
    name: prod-account-service
status:
  binding:
    name: <generated-secret-resource>