Connect to services on Kubernetes easily with kube-service-bindings

One of the projects the Node.js team at Red Hat has been focusing on over the past year is the development of kube-service-bindings for Kubernetes. We've found that combining the Service Binding Operator and kube-service-bindings is a convenient and consistent way of sharing credentials for services, letting you easily secure your deployments.

This article is the first of a three-part series. Our goals in the series are to:

• Introduce Kubernetes service bindings and the Service Binding Operator.
• Explain how the kube-service-bindings NPM package supports service bindings for Node.js applications.
• Cover the clients we've added support for in kube-service-bindings.
• Show an end-to-end deployment of a Node.js application communicating with a database in a Kubernetes setting.

After reading this article and parts two and three of the series, you should have a better understanding of how service bindings and kube-service-bindings work. This first article explains the tools we're using and their benefits for Node.js programmers using Kubernetes.

What are service bindings and the Service Binding Operator?

In our service binding terminology for Kubernetes, a service binding provides information about a service to a process that needs to bind to that service. In subsequent parts of this series, for instance, you will use a service binding to provide the credentials of a MongoDB database when your Node.js application connects to it. The database is called a backing service, while the application is called the workload. The data passed between them is called binding data.

Protocols and rules for sharing information are laid out in the Service Binding Specification for Kubernetes. The Service Binding Operator (SBO) establishes a connection to share the credentials between the workload and backing service. The SBO is implemented by Red Hat and is available in the OpenShift Operator Hub.

The Service Binding Operator has two significant benefits compared to other methods of sharing secrets. The first is security: The SBO requires less exposure of credentials or secrets throughout the CI/CD process. The second benefit is convenience: Rarely is development as easy as dragging a line in a graphical user interface (UI) in the Red Hat OpenShift console.

You can find more information on how the Service Binding Operator works in the article Announcing Service Binding Operator 1.0 GA. The article Simplify secure connections to PostgreSQL databases with Node.js provides information about using the SBO to share credentials among backing services and compares the technique to others, using as an example the PostgreSQL client supported by kube-service-bindings.

In the background, the SBO:

• Passes a variable named SERVICE_BINDING_ROOT to the application environment to direct it to the credentials.
• Projects the binding data into the application container, under the directory /$SERVICE_BINDING_ROOT/<application-name>.

What is kube-service-bindings and how does it work?

kube-service-bindings finds, parses, and transforms data such as credentials into a consumable format appropriate for each client, such as a database. kube-service-bindings checks the SERVICE_BINDING_ROOT environment variable to find which directory in the application instance has the binding data. The presence of the SERVICE_BINDING_ROOT variable indicates that binding data is available. If the environment variable or binding data are not available, kube-service-bindings throws an error, which can easily be discovered through a try/catch block.

Besides parsing the data, kube-service-bindings knows exactly what it takes to provide the right configuration for each client, another advantage to using the package. Our goal in developing kube-service-bindings is to support the most common clients. We started by supporting backing services listed in the General Availability (GA) release for the Red Hat Service Binding Operator, as outlined in the section Extracting the binding data from backing services of the previously mentioned article.

Version 1.0 of kube-service-bindings has made a good start in its support for clients. We would like to prioritize our work based on the needs of the community, so feel free to open a request in the kube-service-bindings repository for the next client you would like to see supported.

Table 1 shows the currently supported clients. To connect to a client, the Node.js program issues a getBinding call, passing the type (column 1) as the first argument and the client (column 2) as the second.

Simplifying access to services on Kubernetes

This article has explained the roles of the Service Binding Operator and kube-service-bindings in making it easy to connect to backing services such as databases. Subsequent articles in this series will go through an example that connects a Node.js application to a database using these tools.