Google Cloud Platform Service Broker

This page provides an overview of the Google Cloud Platform Service Broker.

Introduction

Google Cloud Platform (GCP) Service Broker is an implementation of the open-source Open Service Broker (OSB) API hosted on GCP. It simplifies the delivery of GCP services to applications that run on Kubernetes. By creating GCP resources and managing their corresponding permissions, Service Broker makes it easy to consume GCP services from within a Kubernetes cluster. For example, you can provision an instance of the Cloud Pub/Sub service from within your GKE cluster and make it available to your application(s).

Service Broker is registered on top of the Service Catalog GKE add-on. Once you install Service Catalog in your cluster and add Service Broker, it downloads a list of available services and plans. You can now create instances of plans and assign those instances with required permissions (bindings). Applications in your cluster can now access created service instances via their native APIs. GCP services available via Service Broker are:

You can find samples for each of these services in the Google Cloud Platform GitHub repository.

Concepts

The Google Cloud Platform Service Broker API uses several OSB concepts:

  • Application: Any piece of software that might use or bind to a service instance.
  • Platform: The software that manages the cloud environment into which applications are provisioned and service brokers are registered. Users do not directly provision services from service brokers; rather, they rely on the Platform to manage the services and interact with the service brokers on their behalf. The platform for Google Cloud Platform Service Broker is the Kubernetes Service Catalog.
  • Service: A managed software offering such as Google Cloud Pub/Sub or Spanner. GCP services expose APIs that can be invoked to perform certain actions.
  • Service binding: The ability to use a service instance. This request might refer to an application or some other entity that may wish to use the service instance. In the Kubernetes Service Catalog, information returned in a binding call is placed in a Kubernetes Secret for the specified namespace. Service Broker typically uses a create binding call to set IAM permissions on a service instance.
  • Service broker: Service brokers manage the lifecycle of services. The Kubernetes Service Catalog interacts with service brokers to provision and manage service instances and service bindings.
  • Service instance: An instantiation of a service offering.
  • Service offering: The class of a service that a service broker supports.
  • Service plan: The representation of different options or tiers for a given service offering. This may impact cost.

Architecture

The following diagrams provide a visual overview of the OSB architecture and the flow between Service Catalog and Service Broker for provisioning a service instance and a service binding.

Overview

The following diagram illustrates the architecture of Service Broker.

Service Catalog is a Kubernetes extension API that enables applications running on a Kubernetes cluster to use GCP services, such as Cloud Pub/Sub. Service Catalog communicates with Service Broker to get a list of available services and plans, which can then be provisioned as service instances.

Information about a service instance is stored in the ServiceInstance and ServiceBinding resources. Once a service instance has been provisioned, the access credentials are shared with the application through Kubernetes Secrets.

Listing services and plans

  1. Once the GCP ClusterServiceBroker resource has been installed in the Service Catalog, Service Catalog connects to Service Broker to request the list of available services and plans.
  2. The service details are stored as ClusterServiceClass resources, and their corresponding plans are stored in ClusterServicePlan resources.

See Discovering GCP services and plans for instructions on how to list services and plans.

Service account instance and binding flow

The diagram below illustrates the order of interactions between the Kubernetes Service Catalog and Service Broker in the context of the Cloud IAM Service Account service. Service accounts are necessary to authenticate to GCP resources.

  1. Provision a service instance of a Cloud IAM service account.
  2. GCP provisions a new service account in. It has no permissions at this point.
  3. Service Broker returns an instance provisioning response, which is stored in a ServiceInstance resource.
  4. Provision the service binding for the IAM service account instance.
  5. GCP generates a private key for the service account and returns it to the IAM service account instance.
  6. Service Broker returns the private key for the IAM service account, and a ServiceBinding resource is created.
  7. Service Catalog stores the private key for the service account in a Secret in a specified namespace.
  8. You can use the service account to assign roles to other GCP resources by creating new bindings using this service account as input to the binding call.

GCP service instance and binding flow

The diagram below illustrates the order of interactions between Service Catalog and Service Broker in the context of another GCP service offered by Service Broker, such as Cloud Pub/Sub.

  1. Provision a service instance with a service plan. For example, you can provision the Cloud Pub/Sub service with Plan 1.
  2. GCP provisions a new instance of the resource in the project. For Cloud Pub/Sub, GCP provisions a new Pub/Sub Topic.
  3. Service Broker returns an instance provisioning response, which is stored in a ServiceInstance resource.
  4. Provision the service binding for the service instance with parameters defined by the service plan. For Cloud Pub/Sub, this includes IAM publisher or subscriber permissions.

    • Specify the service account to use.

    • Specify the IAM roles to assign to the service account.

  5. Set the IAM permissions for the service account. Depending on the resource type, this might be:

    • IAM permissions on the resource itself, as would be the case for a Spanner service instance.

    • IAM permissions at the project level for those resources that don't support resource-specific permissions

  6. Service Broker returns the connection information for the service, and a ServiceBinding resource is created.

  7. Service Catalog stores the connection information for the service in a Secret specified in a namespace.
  8. The service binding information, which includes the connection credentials, is shared with the application using a Kubernetes Secret.
  9. The application uses the binding information to connect with and access the service, such as Cloud Pub/Sub.

Optional: You can create additional bindings, using different service accounts and different sets of roles, within the same namespace to the same service instance. This can help different applications in the same Kubernetes namespace use the same Pub/Sub topic.

See Using a GCP service for instructions on how to provision and bind to a service instance.

Deprovisioning and cleanup flow

The diagram below illustrates how to deprovision a service when it is no longer needed. This should be done to avoid incurring charges to your GCP account for a service that is no longer in use.

  1. Delete the Service Binding. Service Catalog sends a request to Service Broker to unbind the service.
  2. GCP deletes the IAM permissions for the service instance.
  3. Service Broker returns a binding deletion response.
  4. Delete the Kubernetes Secret containing the service binding and connection information.
  5. Delete the Service Instance. Service Catalog sends a request to Service Broker to deprovision the service.
  6. GCP deletes the service instance. For Cloud Pub/Sub, it deletes the Pub/Sub Topic.
  7. Service Broker returns a deprovisioning response.

See Service Catalog clean up for instructions on how to delete the service instance and binding.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Kubernetes Engine