[Proposition]: Design a bindology service able to map the consumer and service provider parameters

[cmoulliard]

Proposition

The Service Binding Operator and the Service Binding spec do not really handle a contract definition (= what a consumer application and a service provider will share as list of parameters passed within a secret to configure a datasource, MongoDB, MySQL, ...) as only 2 fields are currently defined as recommended part of the spec: type and provider.

The consequence is that it is still needed that both (= consumer and provider) verify before to bind a service how the secret should be populated to match exactly what the runtime library expect to get and to consume from the workload projection (= where key/values will be stored under the runtime local filesystem mounted from a volume).

To overcome this problem, we propose to design a new service able to perform what it is described hereafter:

• First, it is needed to define, part of a glossary (or bindology), the mappings of some well known services (Postgresql, MySQL, Kafka, A-MQ, Keycloak, ...) and their ServiceBinding Tool's counterpart (see example herefater)
• Next, setup a github flow action, able top of a quarkus release (and quarkiverse extensions) to extract from the existing quarkus code the different properties (datasource, mssql, kafka, mongodb, etc) and to bind them against their corresponding binding parameter (or using a dictionary of synonyms) in a YAML file (optional)
• The YAML file should be hosted under the quarkus github server and be consumable as RAW YAML URL (optional)
• The ServiceBinding tool (running on k8s) can then consume the YAML file of the properties mapped (this file can be pouplated dynamically or manually) to know how to bind/map the parameters they collect (= from a Secret populated by an operator, from a k8s secret if created manually or using SBO, from a different approach) to what the runtime and resource (datasource, etc) expects to have/get

The YAML created/generated file could help to do:

To map them using a glossary to something that the servicebinding tool understands. Example: The datasource expects to get by example the property jdbc-url - https://quarkiverse.github.io/quarkiverse-docs/quarkus-jdbc-sqlite/dev/datasource.html. Such a property/parameter is relevant for a java application/runtimes, will be different for nodejs, etc and is not understandable as such by the ServiceBinding tool. If now, we declare somewhere that the property jdbc-url for the java runtimes matches the service binding url, than the SB tool will be able to populate correctly the following projection

apiVersion: v1
kind: Secret
metadata:
  name: production-db-secret
type: servicebinding.io/mysql
stringData:
  type: postgresql   // ServiceBinding spec mandatory param
  provider: bitnami   // ServiceBinding spec mandatory param
  jdbc.url: jdbc:<postgresql>:://<url>:<port>/<database_name> // Java Runtime mandatory param matching service endpoint url
  username: <username_collected_from_vault> // Username to be used to access a service as declared in a vault key secret
  password: <password_collected_from_vault> // Password to be used to access a service as declared in a vault key secret

Where the mapping can take place

We have potentially 2 options, depending where we prefer to do the mapping :

• Application Lib: We improve the spec and extend it to define for different binding types (datasource or db, kafka, mongodb, ...) the parameters they must return part of the secret, response AND then we rely on Application Client Lib to map the binding parameters with their internal parameters (e.g. https://github.com/quarkusio/quarkus/blob/main/extensions/kubernetes-service-binding/runtime/src/main/java/io/quarkus/kubernetes/service/binding/runtime/DatasourceServiceBindingConfigSourceFactory.java#L36). This is what we try todo today without success !
• Service Binding / Primaza: We design, part of Primaza, a bindology (word is coming from Ioannis to refer to a glossary of common parameters and their mappings) to let Primaza to return according to the Claim + Runtime type the parameters they expect to get (= sort of contract definition)

WDYT ? @iocanel

[iocanel]

The way I understand things in order to perform mapping we need to understand both how the consumer names things but also how the producer. Let's identify first these two:

• producer: The one that produces the secret with the binding information. It can be a helm chart or operator.
• consumer: The application that needs that needs to get the binding information using workflow projection.

Given the lack of a standard mechanism of communicating binding information, there is no way that consumer and producer can be aligned. And this is where mapping and the idea of bindology comes in:

By defining a standard way of naming things and providing mappings for all known producers and consumers we can possibly perform the actual mapping. However, this is something that I feel that needs a little bit of reasearch.

So, we first need to define a group of known producers and see what data they are exposing.
Then we need to do the same of consumers (though it feels that this issue refers mainly to quarkus).

[cmoulliard]

• producer: The one that produces the secret with the binding information. It can be a helm chart or operator.
  This idea, which was developed part of the spec, where finally an application (= Service provider) will be able to generate secrets dot not work for different reasons:

• Lack of support of the specification,
• Lack of the adhesion by the service provider to developp Kubernetes Operator,
• Difficulty to manage several secrets to access a DB instance
• Lack of security around the credentials shared

[cmoulliard]

Given the lack of a standard mechanism of communicating binding information, there is no way that consumer and producer can be aligned. And this is where mapping and the idea of bindology comes in:

Yes !!

[cmoulliard]

By defining a standard way of naming things and providing mappings for all known producers and consumers we can possibly perform the actual mapping.

Ideally such a mapping should be become part of a contract (= sort of mapping defined for resource type: datasource, etc) definition, stored part of Primaza and used between the consumer (= application claiming to access a service) and Primaza (= actor acting as proxy between an application = the runtime and a Service provider.

[cmoulliard]

Should we like crossplane define such mappings using a YAML template with patches and From/To maps (https://docs.crossplane.io/knowledge-base/guides/composition-functions/ or https://gist.github.com/cmoulliard/755d62e0797140f7cab85825256930cd#file-gistfile1-txt-L89) ? @iocanel @aureamunoz @Sgitario

See composition reference doc explaining how they map/transform, etc: https://docs.crossplane.io/v1.12/concepts/composition/#compositions