Install the Crossplane Service Broker

The Crossplane Service Broker will manage Crossplane custom resources in the same cluster as it runs itself. It must be provided with a least one service id to handle.

Preparations

  • Have access to a Kubernetes cluster with Crossplane installed.

Configuration

The Crossplane Service Broker is configured through environment variables. A typical deployment may look like the following YAML.

After you created the file deployment.yaml below, run this command to install the Crossplane Service Broker in your Kubernetes cluster:

kubectl apply -f deployment.yaml
deployment.yaml
kind: Namespace (1)
apiVersion: v1
metadata:
  labels:
    name: service-broker
  name: service-broker
---
kind: Deployment (2)
apiVersion: apps/v1
metadata:
  name: service-broker-test (3)
  namespace: service-broker
  labels:
    name: service-broker-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/instance: test
      app.kubernetes.io/name: service-broker
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: test
        app.kubernetes.io/name: service-broker
        name: service-broker-test
    spec:
      containers:
        - name: service-broker
          image: quay.io/vshn/crossplane-service-broker:v0.4.1
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          env: (4)
            - name: OSB_NAMESPACE
              value: crossplane-services
            - name: OSB_USERNAME
              value: test
            - name: OSB_PASSWORD
              value: changeMeEventually
            - name: OSB_SERVICE_IDS
              value: redis-k8s,3a385e26-cdfc-46bc-961b-69892684af8b,16379f5f-0c5f-4c55-a119-fd063af62919
            - # Used for Bearer Token Validation
              name: OSB_JWT_KEYS_JWK_URL
              value: https://auth.corp.internal/jwks
          resources:
            limits:
              cpu: 500m
              memory: 128Mi
            requests:
              cpu: 200m
              memory: 64Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: http
              scheme: HTTP
          readinessProbe:
            httpGet:
              path: /healthz
              port: http
              scheme: HTTP
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: Always
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      serviceAccountName: service-broker
      serviceAccount: service-broker
      schedulerName: default-scheduler
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  minReadySeconds: 30
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
kind: Service (5)
apiVersion: v1
metadata:
  name: service-broker-test
  namespace: service-broker
  labels:
    app.kubernetes.io/instance: test
    app.kubernetes.io/name: service-broker
    name: service-broker-test
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: http
  selector:
    app.kubernetes.io/instance: test
    app.kubernetes.io/name: service-broker
  type: ClusterIP
  sessionAffinity: None
1 This part of the YAML ensures that a Kubernetes namespace called service-broker exists.
2 This part of the YAML initiates the actual Deployment of the service broker.
3 This line defines the name of your Crossplane Service Broker. Don’t change it for now, as this guide relies on it being called service-broker-test.
4 See below for an explanation of the environment variables that are defined here.
5 In order for the service catalog to discover and access the Crossplane Service Broker, a Kubernetes Service is created. It conveniently also takes care of the load balancing between the two instances of the Crossplane Service Broker that get deployed.

Take note of the environment variables that are configured in the above deployment.yaml:

Variable Name Description Example Value

OSB_SERVICE_IDS

The Crossplane Service Broker must know which services it’s responsible for. The ID can be any arbitrary string, though often this is a UUID.

redis-k8s,3a385e26-cdfc-46bc-961b-69892684af8b,16379f5f-0c5f-4c55-a119-fd063af62919

OSB_NAMESPACE

This is the namespace in which the Crossplane Service Broker will create it the relevant Crossplane custom resources.

crossplane-services

OSB_USERNAME

This is the username which is used when doing Basic auth between the Service Catalog and the Service Broker. If you don’t use basic auth, choose a random string here.

test

OSB_PASSWORD

This is the password which is used when doing Basic auth between the Service Catalog and the Service Broker. If you don’t use basic auth, choose a random string here.

changeMeEventually

OSB_JWT_KEYS_JWK_URL

This URL is queried during the startup of the service broker. It contains the public keys in JWK-format that should be used to verify the validity of the JWT tokens.

Learn more about this in the HTTP Bearer Token authentication how-to.

https://auth.corp.internal/jwks