Allow a custom structure of Kubernetes secrets by introducing secretTemplate to serviceBindingsadd secret template

[rinckm]

Pull Request Template

Prerequisites

This feature addresses the issue in #202, which was reopened in #229

Motivation

The Kubernetes secrets created by SAP BTP Service Operator for service bindings have a fixed content structure. This structure might not be suitable for any application.

As an example the elasticsearch-exporter expects a secret in following format to get the secret with envFrom: - secretRef::

apiVersion: v1
kind: Secret
stringData:
  ES_PASSWORD: password1 //Base64string

We can not specify the key/values pair to in SAP BTP Service Operator. The servicekey could contain the wrong keys, that will not be understood by elasticsearch-exporter.

{
  "psw": "password1",
}

So there is no way to use this component without an adapter. Or without forking and modifying it.

Approach

We added a new field secretTemplate to the serviceBinding CRD. This will allow the user to specify a Go template to create a custom structured Kubernetes secret. To solve the Problem from our example, the serviceBinding would look like that:

  apiVersion: services.cloud.sap.com/v1
  kind: ServiceBinding
  metadata:
      namespace: ns1
      name: serviceBinding1
  spec:
      serviceInstanceName: serviceInstance1
      externalName: serviceInstance1
      secretTemplate: |-
        apiVersion: v1
        kind: Secret
        stringData:
           ES_PASSWORD: {{ .smBindingCredentials.psw | quotes }}

Please have a look at our extended description in the README for more information.

What we also considered is:

• users should not cause a memory overflow by defining huge templates. We restricted this by our own writer implementation LimitedWriter.

We are already using our own Release of the BTP Service Operator with this Feature in our clusters.

Pull Request status

• Initial implementation
• Refactoring
• Unit tests
• Integration tests

Third-party code

We used the Sprig template functions library to enable more functions.

Work in Progress label

For as long as development of your Pull Request is still ongoing you MUST label it with a wip label as well as prefix the name of the PR with [WIP].

For example: [WIP] Service brokers API

[rinckm]

This is a copy of #228

[pre]

Could we extend the template so that it'd be possible to define labels to the generated Secret ? This is not currently possible, which makes it difficult to consume the generated ServiceBinding Secret in ArgoCD. See #360 for details.

[anbrsap]

Could we extend the template so that it'd be possible to define labels to the generated Secret ? This is not currently possible, which makes it difficult to consume the generated ServiceBinding Secret in ArgoCD. See #360 for details.

@pre Labels and annotations can be defined in secret templates.

Edit:

Didn't read #360. So although in secret templates labels and annotations can be defined, they are not inherited from the ServiceBinding.

This pull request introduces secret templates as an alternative to the default secret generation. I would not add further features here which are not already available for the default secret generation.

[rinckm]

Could we extend the template so that it'd be possible to define labels to the generated Secret ? This is not currently possible, which makes it difficult to consume the generated ServiceBinding Secret in ArgoCD. See #360 for details.

@pre Labels and annotations can be defined in secret templates.

See also https://github.com/rinckm/sap-btp-service-operator/blob/main/README.md#metadata-section

[pre]

This pull request introduces secret templates as an alternative to the default secret generation. I would not add further features here which are not already available for the default secret generation.

Sounds reasonable. The use case for #360 could benefit from generating the Secret using a template anyway. We need to know the expected keys in that Secret before hand, in order to map them in the ArgoCD configuration.

So even though #360 is different, this Pull Request provides a nice alternative to the workaround we're currently using (external-secrets operator).

[pre]

@kerenlahav how come this PR was closed as stale without any comment from the project’s maintainers?

What was missing to get this merged?

Are pull requests possible in this project in the first place?

[kerenlahav]

#398