Configure Service Binding Credentials

This guide describes how to expose credentials for a service binding.

The service bindings concepts documentation introduced the idea that a service bindings can return arbitrary credentials to the end-user upon successful provisioning. Credentials are meant to communicate data to the end-user that allow the service to be consumed when a URL is insufficient, however can communicate any data you wish. Common examples for credentials data include TLS certificates for validation, or service binding specific—as opposed to service instance specific—authentication credentials.

Credentials Overview

Credentials should always be configured for a service binding. The Service Broker places no restrictions on the content and structure of credentials other than it must be a JSON object when read from the registry. Whether or not credentials are returned to the end-user is completely under your control.

Returning Credentials

Whether or not credentials are returned to the user is dependent up whether the credentials registry key is populated during service instance or service binding generation (the service instance registry is inherited by the service binding registry). The registry and system-defined registry keys are discussed further in the registry concepts documentation.

Configuring Credentials

Consider the following configuration:

apiVersion: servicebroker.couchbase.com/v1alpha1
kind: ServiceBrokerConfig
spec:
  templates:
  - name: credentials-snippet (1)
    template: {} (2)
    parameters:
    - name: username (3)
      required: true
      source:
        registry: username
      destinations:
      - path: /username
    - name: password (4)
      required: true
      source:
        registry: password
      destinations:
      - path: /password
  bindings:
    serviceBinding: (5)
      parameters: (6)
      - name: credentials
        source:
          template: credentials-snippet (7)
        destinations:
        - registry: credentials (8)

These are the relevant things to note:

1	Credentials must be a JSON object, so we use a template to generate them.
2	The template starts as an empty object, however you can add static configuration or provide defaults.
3	The template requires that a `username` attribute be added to the credentials object. The `username` must be defined in the registry, how it is defined is up to you. For service binding specific entities it may be derived from the `binding-id` registry entry.
4	The template requires that a `password` attribute be added to the credentials object. The `password` must be defined in the registry, how it is defined is up to you. Passwords are typically ephemerally created using the generate password parameter generator.
5	Credentials are usually defined for service bindings as they contain per-service binding credentials such as user names and passwords. They may be defined for the service instance if all that needs to be defined is specific to the service instance e.g. TLS CA certificates.
6	Credentials may be defined during template processing, but are usually defined by the configuration binding for clarity.
7	Credentials are sourced by referencing the configuration template snippet. This will lookup and render the template before returning the result.
8	The make the Service Broker aware that credentials need to be returned, set the `credentials` registry key. This value will be returned when a service binding request is successfully created.