Deploy Kong Mesh on Universal
To start learning how Kong Mesh works, you run and secure a simple demo application that consists of two services:
-
demo-app
: a web application that lets you increment a numeric counter. It listens on port 5000 -
redis
: data store for the counter
--- title: service graph of the demo app --- flowchart LR demo-app(demo-app :5000) redis(redis :6379) demo-app --> redis
Prerequisites
- Redis installed
- Demo app downloaded from GitHub:
git clone https://github.com/kumahq/kuma-counter-demo.git
- Optional: To explore traffic metrics with the demo app, you also need to set up Prometheus. See the MeshMetric policy documentation.
Install Kong Mesh
Generate tokens
Create a token for Redis and a token for the app (both are valid for 30 days):
kumactl generate dataplane-token --tag kuma.io/service=redis --valid-for=720h > kuma-token-redis
kumactl generate dataplane-token --tag kuma.io/service=app --valid-for=720h > kuma-token-app
This requires authentication unless executed against a control-plane running on localhost. If
kuma-cp
is running inside a Docker container, see docker authentication docs.
Create a data plane proxy for each service
Because this is a quickstart, we don’t setup certificates for communication between the data plane proxies and the control plane. You’ll see a warning like the following in the
kuma-dp
logs:
2024-07-25T20:06:36.082Z INFO dataplane [WARNING] The data plane proxy cannot verify the identity of the control plane because you are not setting the "--ca-cert-file" argument or setting the KUMA_CONTROL_PLANE_CA_CERT environment variable.
This isn’t related to mTLS between services.
For Redis:
kuma-dp run \
--cp-address=https://localhost:5678/ \
--dns-enabled=false \
--dataplane-token-file=kuma-token-redis \
--dataplane="
type: Dataplane
mesh: default
name: redis
networking:
address: 127.0.0.1
inbound:
- port: 16379
servicePort: 26379
serviceAddress: 127.0.0.1
tags:
kuma.io/service: redis
kuma.io/protocol: tcp
admin:
port: 9901"
For the demo app:
kuma-dp run \
--cp-address=https://localhost:5678/ \
--dns-enabled=false \
--dataplane-token-file=kuma-token-app \
--dataplane="
type: Dataplane
mesh: default
name: app
networking:
address: 127.0.0.1
outbound:
- port: 6379
tags:
kuma.io/service: redis
inbound:
- port: 15000
servicePort: 5000
serviceAddress: 127.0.0.1
tags:
kuma.io/service: app
kuma.io/protocol: http
admin:
port: 9902"
Deploy the demo application
- Run
redis
as a daemon on port 26379 and set a default zone name:redis-server --port 26379 --daemonize yes redis-cli -p 26379 set zone local
- Install and start
demo-app
on the default port 5000:npm install --prefix=app/ npm start --prefix=app/
- In a browser, go to 127.0.0.1:5000 and increment the counter.
Explore the GUI
You can view the sidecar proxies that are connected to the Kong Mesh control plane:
Introduction to zero-trust security
By default, the network is insecure and not encrypted. We can change this with Kong Mesh by enabling the Mutual TLS policy to provision a Certificate Authority (CA) that will automatically assign TLS certificates to our services (more specifically to the injected data plane proxies running alongside the services).
Before enabling Mutual TLS (mTLS) in your mesh, you need to create a MeshTrafficPermission
policy that allows traffic between your applications.
If you enable mTLS without a
MeshTrafficPermission
policy, all traffic between your applications will be blocked.
- To create a
MeshTrafficPermission
policy that allows all traffic, do the following:
echo 'type: MeshTrafficPermission
name: allow-all
mesh: default
spec:
targetRef:
kind: Mesh
from:
- targetRef:
kind: Mesh
default:
action: Allow' | kumactl apply -f -
- To create a
Mesh
policy with a builtin CA backend, do the following:
echo 'type: Mesh
name: default
mtls:
enabledBackend: ca-1
backends:
- name: ca-1
type: builtin' | kumactl apply -f -
Once Mutual TLS has been enabled, Kong Mesh will not allow traffic to flow freely across our services unless we explicitly have a Traffic Permission policy that describes what services can be consumed by other services. By default, a very permissive traffic permission is created.
For the sake of this demo, we will delete it:
kumactl delete traffic-permission allow-all-default
You can try to make requests to the demo application at 127.0.0.1:5000/
and you will notice that they will not work.
Now, let’s add back the default traffic permission:
echo 'type: MeshTrafficPermission
name: allow-all
mesh: default
spec:
targetRef:
kind: Mesh
from:
- targetRef:
kind: Mesh
default:
action: Allow' | kumactl apply -f -
By doing so every request, we now make sure our demo application at 127.0.0.1:5000/
is not only working again, but it’s automatically encrypted and secure.
As usual, you can visualize the Mutual TLS configuration and the Traffic Permission policies we have just applied via the GUI, the HTTP API or
kumactl
.
Next steps
- Explore the Features available to govern and orchestrate your service traffic.
- Add a gateway to access the demo from the outside by following the builtin gateway guide.
- Add Kong as gateway to access the demo from the outside by following the delegated gateway guide.
- Federate zone into a multizone deployment.
- Learn more about what you can do with the GUI.
- Read the full documentation to learn about all the capabilities of Kong Mesh.