Kubernetes Service Binding Spec
Jeffrey Ellin
Why Service Bindings
Service Bindings
Kubernetes-wide specification for communicating service secrets to workloads in an automated way.
Concept adopted from Cloud Foundry and Heroku
Allows developers to focus on business value and not utility code
{Application Developer}
expects secrets to be exposed consistently and predictably
# Devloper
As a Developer I need a cloud agnostic way to consume credentials
Workload Projection
$SERVICE_BINDING_ROOT
├── account-database
│ ├── type
│ ├── provider
│ ├── uri
│ ├── username
│ └── password
└── transaction-event-stream
├── type
├── connection-count
├── uri
├── certificates
└── private-key
# Developer
# Developer
Language Runtimes
Java Sample
import com.nebhale.bindings.Binding;
import com.nebhale.bindings.Bindings;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class Application {
public static void main(String[] args) {
Binding[] bindings = Bindings.fromServiceBindingRoot();
bindings = Bindings.filter(bindings, "postgresql");
if (bindings.length != 1) {
System.err.printf("Incorrect number of PostgreSQL drivers: %d\n", bindings.length);
System.exit(1);
}
String url = bindings[0].get("url");
if (url == null) {
System.err.println("No URL in binding");
System.exit(1);
}
Connection conn;
try {
conn = DriverManager.getConnection(url);
} catch (SQLException e) {
System.err.printf("Unable to connect to database: %s", e);
System.exit(1);
}
// ...
}
}
# Developer
{Service Provider}
expects secrets to be collected consistently and predictably
Crossplane Composite Resource
apiVersion: example.dev/v1beta1
kind: Database
metadata:
name: database-service
...
status:
binding:
name: production-db-secret
# Service Provider
Crossplane Secret
apiVersion: v1
kind: Secret
metadata:
name: production-db-secret
stringData:
type: mysql
provider: bitnami
host: localhost
port: 3306
username: root
password: root
# Service Provider
Well Known Secret Entries
Apart from the special type
, and provider
entries in the Secret
data, there are few special words called well-known entries.
Name | Requirements |
---|---|
host | A DNS-resolvable host name or IP address |
port | A valid port number |
uri | A valid URI as defined by RFC3986 |
username | A string-based username credential |
password | A string-based password credential |
certificates | A collection of PEM-encoded X.509 certificates, representing a certificate chain used in mTLS client authentication |
private-key | A PEM-encoded private key used in mTLS client authentication |
# Service Provider
{Application Operator}
expects secrets to be transferred from services to workloads consistently and predictably
Application operators bind application workloads with services by creating ServiceBinding
resources.
kind: ServiceBinding
apiVersion: servicebinding.io/v1beta1
kind: ServiceBinding
metadata:
name: account-service
spec:
service:
apiVersion: com.example/v1alpha1
kind: AccountService
name: prod-account-service
workload:
apiVersion: apps/v1
kind: Deployment
name: online-banking
# Application Operator
Multiple Workloads
apiVersion: servicebinding.io/v1beta1
kind: ServiceBinding
metadata:
name: online-banking-frontend-to-account-service
spec:
name: account-service
service:
apiVersion: com.example/v1alpha1
kind: AccountService
name: prod-account-service
workload:
apiVersion: apps/v1
kind: Deployment
selector:
matchLabels:
app.kubernetes.io/part-of: online-banking
app.kubernetes.io/component: frontend
# Application Operator
Further Info
Crossplane
ServiceBinding
Specification
Tanzu Application Platform
Further Info
https://slack.crossplane.io/
Kubernetes Service Bindings
By Jeffrey Ellin
Kubernetes Service Bindings
- 157