Google Cloud Platform Service Broker

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


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 Kubernetes Engine cluster and make it available to your application(s).

Service Broker is registered on top of the Service Catalog Kubernetes Engine 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.


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.


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


The following diagram demonstrates the architecture of Service Broker.

Service Account Instance and Binding Flow

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

Kubernetes Service Catalog Google Cloud Platform Service Broker
Provision Service Instance of an IAM Service Account.
Provision a new service account in GCP. It has no permissions at this point.
Provision the service binding for the IAM service account instance.
Generate a private key for the service account and return it to the IAM service account instance.
Place the private key for the service account into the secret for the specified namespace. It can now be used to assign roles to other GCP resources.

GCP Service Instance and Binding Flow

The table below illustrates the order of interactions between Service Catalog and Service Broker in the context of another service offered by Service Broker.

Kubernetes Service Catalog Google Cloud Platform Service Broker
Provision the service instance (for example, Pub/Sub Service with the Beta Plan).
Provision a new instance of the resource in the project (for example, provision a new Pub/Sub Topic).
Provision the service binding to the service instance
  • Specify the service account to use and use the private key for that service account.
  • Specify the IAM roles to assign to the service account.
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
(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 could help different applications in the same Kubernetes namespace use the same Pub/Sub topic.

What's next

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

Send feedback about...

Kubernetes Engine