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:

      kind: ServiceBrokerConfig
        - name: credentials-snippet (1)
          template: {} (2)
          - name: username (3)
            required: true
              registry: username
            - path: /username
          - name: password (4)
            required: true
              registry: password
            - path: /password
          serviceBinding: (5)
            parameters: (6)
            - name: credentials
                template: credentials-snippet (7)
              - 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.