When connecting applications to backing services (e.g. databases, message queues) on Kubernetes, supplying the correct credentials and connection information to the workload requires knowledge of both sides of the transaction. Classically, the data has to be known beforehand and is provided for the application through a mounted Secret or some other sort of configuration. The way in which secrets are exposed by services and the mounted locations expected by applications to consume them can differ greatly, often necessitating manual configuration.
Assume we have an application (e.g Java with Quarkus) that needs a database (e.g. PostgreSQL). When we install the database on Kubernetes it usually creates an application user with a password in a Secret. The application then needs this information and more, e.g. a jdbc-url, to connect to the database.
The Service Binding for Kubernetes specification helps provide the necessary information to the application. It aims to simplify the process by defining how Secrets get exposed, called and mounted predictably. Ideally, connecting an application to a backing service should be as easy as simply referencing the service itself, with no knowledge of its internal deployment structure, and having the secrets accessible with no further configuration.
On actual Kubernetes clusters the Service Binding specification is implemented by an Operator. The Operator maps the secret of a backing service into the application.
The mapping between backing-service and application is done with the help of a CRD (custom resource definition). In practice the operator creates a new secret that is injected into the application.
The Red Hat Service Binding Operator is an implementation of the Service Binding specification. The mapping is defined in ServiceBinding custom resources. In them, one or more specification-compliant backing services are referenced, as well as the application they should be mounted in.
Be aware however, that it can be configured with two different CRDs
The first one is the CRD according to the specification. The latter provides a few additional features that are quite convenient, but are not part of the standard specification.
In order to be compliant with the recommended way of exposing information, according to the specifications, a backing service has to fit the Provisioned Service schema. To do so, it declares its secret in the .status.binding field of its yaml. At this point only few CRDs one might come across support this, making the use relatively unlikely. Until adoption of the standard has become more widespread, a good alternative is provided via the use of annotations. A backing service can reference sources for the binding information it wishes to provide in its metadata. This is possible due to the Red Hat Service Binding Operator’s implementation of the Secret Generation Extension of the Service Binding specification.
Finally, there is the option of just directly referencing an existing Kubernetes Secret instead of a backing service inside the ServiceBinding. The benefit of not having to know the location of secret information, which is one of the major advantages of the specification in the first place, is lost this way. However, there is still some added flexibility and modularity with this method which makes it worth considering.
The specification intending to standardize the way applications and the services they rely upon are connected is a promising prospect for the future. It would simplify a part of deploying and maintaining applications to Kubernetes clusters that currently varies wildly. A standard is only as good as the compliance to it, however, and as of right now there is not a lot of adoption happening. This is partly the case due to the relatively recent release of the standard but higher proliferation would still be desirable.
Independent of the specification itself, the Operator is currently the star of the show, as it opens up a lot of options for linking secrets to applications even with nonconforming backing services. There are already some concrete use-cases we are considering to use ServiceBindings in. We definitely recommend experimenting with it and are excited to see how it is going to change our own processes.
