Connect the Service Catalog to a Service Broker

This tutorial is deprecated. Some links may not work.

This how-to will explain how a Service Catalog is connected to the Crossplane Service Broker.

Preparations

Have access to an authentication server from which you can request Bearer Tokens.
Have a Crossplane Service Broker in your cluster that’s configured for HTTP Bearer Token authentication.
Have a Service Catalog running on your cluster.
Have svcat installed on your computer.

Configuring HTTP Bearer Token Authentication

For the following instructions, change to the catalog namespace of your cluster:

kubectl config set-context --current --namespace=catalog

In order to connect the Service Catalog to the Crossplane Service Broker, we’ll have to provide the Service Catalog with some credentials. These credentials are used by the Service Catalog to identify itself to the Crossplane Service Broker. In this how-to, we focus on Bearer Token authentication. The advantage of the Bearer Token authentication is that the Crossplane Service Broker can restrict the offered services based on information provided in the Bearer Token.

If you don’t need to use Bearer Token authentication, you may want to fall back to Basic authentication. This would typically be the case when your Crossplane Service Broker is only serving one team, group or customer anyways, or in other words: It’s a single tenant system instance.

The Setup HTTP Basic authentication how-to covers that.

The Service Catalog will read the Bearer Token from a Kubernetes secret resource. Therefore we need to get the Bearer Token from the authentication server and create a Kubernetes secret with it:

TOKEN=$(kubectl run \
  --namespace default \
  --attach --rm --quiet \
  "curl-$(date +%s)" \
  --image=docker.io/curlimages/curl -- \
  --silent --request POST \
  --data "grant_type=client_credentials" \
  --data "client_id=950aaaa5-a656-4a8c-8515-aa505a550a52" \
  --data "client_secret=5a2924a5-050a-445a-aa5a-0a50a445a845" \
  "https://auth.corp.internal/token" | jq -r .access_token)
printf "----BEGIN TOKEN----\n${TOKEN}\n----END TOKEN----\n\n"
kubectl create secret generic bearer-creds "--from-literal=token=${TOKEN}" --dry-run=client -o yaml | kubectl apply -f -

Don’t forget to change the values client_id, client_secret and the URL in the command above.

The token that’s issued by the authentication server may only be valid for a short time. (The token which was shown before in the HTTP Bearer Token authentication section was only valid for 600 seconds, that’s just 10 minutes.)

In that case you will need to deploy a kube-token-refresher. The Setup Kube Token Refresher how-to covers the setup. The token refresher will ensure that the service catalog always has a valid Bearer Token.

Register the Crossplane Service Broker at the Service Catalog

Now, finally, we must register the Crossplane Service Broker at the Service Catalog. The Service Catalog will immediately query the Crossplane Service Broker about the services it offers. It (the Service Catalog) will then updates its catalog of all the services that can be provided by our (and all other) registered Service Brokers.

To register the Crossplane Service Broker run the following command.

svcat register servicebroker-test --bearer-secret bearer-creds --url "http://service-broker-test.service-broker"

It should then be possible to interact with this instance of the Crossplane Service Broker through the Service Catalog:

# List all registered service brokers and their status
svcat get brokers

# Show the services that are available to order.
svcat marketplace