Created on 2018-03-07 by Adam Szecówka (@aszecowka).
The Service Catalog in Kubernetes implements the Open Service Broker API. The main goal of the Service Catalog is to provide a way for Kubernetes users to consume services managed by the brokers, and to easily configure their applications with no need for the detailed knowledge of how those services are created or managed. To learn more about the Service Catalog, see this documentation.
The workflow is as follows:
- The administrator creates a ServiceInstance in a given Namespace.
- The administrator creates a binding to the ServiceInstance, to allow the application access the provisioned service.
The binding operation results in creating Kubernetes Secret in a given Namespace.
When the administrator wants to enable the same ServiceInstance (i.e. the same database instance) to two different applications, it is necessary to create two separate bindings, one for each application. The broker returns a new set of credentials every time, if supported by a given ServiceClass.
For example: the Azure Broker acts like this in case of PostgreSQL. For more information on the binding operation in the Azure Broker, see the Azure Broker documentation. In case of the Helm Broker, which provisions Redis, the same credential is returned every time, because of the Redis security model. Even then, the administrator should create separate bindings.
It is recommended to use the synchronous binding, as the specification for the asynchronous binding is still in Alpha stage.
Accepted on 2018-03-07.
The service detects the interactions from different applications using separate credentials.
According to the Kubernetes documentation, Namespace is a security boundary. If the Secret exists in the Namespace, the administrator can inject it to any deployment.
NOTE: The Service Broker cannot prevent other applications from consuming a created Secret. If a stronger isolation level is required, use a dedicated Namespace. For more details, see the Kubernetes issue #4957.