A builtin gateway
Dataplane with no additional configuration does nothing.
It is simply an unconfigured unit of proxying capacity.
To make use of it, we need to place a
MeshGateway resource on it.
MeshGateway resource specifies what network ports the gateway should listen on and how network traffic should be accepted.
A builtin gateway Dataplane can have exactly one
MeshGateway resource bound to it.
This binding uses standard Kuma matching semantics.
The most important field in the
MeshGateway resource is the listener field.
MeshGateway can have any number of listeners, where each listener represents an endpoint that can accept network traffic.
To configure a listener, you need to specify the port number, the network protocol, and (optionally) the hostname to accept.
Each listener has its own set of Kuma tags so that Kuma policy configuration can be targeted to specific listeners.
The selectors field matches Dataplane tags to determine which Dataplanes will be configured with this
The listeners field is an array of listeners for the Gateway.
In this example, the Gateway will listen for HTTP protocol connections on TCP port 8080.
MeshGateway doesn’t specify which IP addresses will be listened on; that is done in the Dataplane resource.
Since HTTP has a protocol-specific concept of hostname, this listener can specify a hostname that it is willing to accept requests for.
It is common to configure HTTP proxies to accept requests for more than one hostname. The Gateway resource supports this by merging listeners that have a common port. Whether merging listeners is allowed depends on the semantics of the protocol field. It is allowed for the most common protocols, HTTP and HTTPS.
Above shows a
MeshGateway resource with two HTTP listeners on the same port.
In this example, the gateway proxy will be configured to listen on port 8080, and accept HTTP requests both for hostnames.
Note that because each listener entry has its own Kuma tags, policy can still be targeted to a specific listener. Kuma generates a set of tags for each listener by overlaying the tags from the listener onto the tags from the Dataplane to which the Gateway is matched. This set of listener tags is what Kuma will match policies against.
| ||Listener tags||Final Tags|
The reference doc contains all options on
# TLS Termination
TLS sessions are terminated on a Gateway by specifying the "HTTPS" protocol, and providing a server certificate configuration. Below, the gateway listens on port 8443 and terminates TLS sessions.
The server certificate is provided through a Kuma datasource reference, in this case naming a secret that must contain both the server certificate and the corresponding private key.
# Server Certificate Secrets
A TLS server certificate secret is a collection of PEM objects in a Kuma datasource (which may be a file, a Kuma secret, or inline data). There must be at least a private key and the corresponding TLS server certificate. The CA certificate chain may also be present, but if it is, the server certificate must be the first certificate in the secret.
Kuma gateway supports serving both RSA and ECDSA server certificates.
To enable this support, generate two server certificate secrets and provide them both to the listener TLS configuration.
kumactl tool supports generating simple, self-signed TLS server certificates. The script below shows how to do this.
kumactl apply -f <( cat<<EOF type: Secret mesh: default name: foo-example-com-certificate data: $(kumactl generate tls-certificate --type=server --hostname=foo.example.com --key-file=- --cert-file=- | base64 -w0) EOF )