MeshExternalService

Uses: Kong Mesh
Related Documentation
Minimum Version
Kong Mesh - 2.8

This resource is experimental.

The MeshExternalService resource allows services running inside the mesh to consume services that are not part of the mesh. You can declare external resources instead of relying on a MeshPassthrough policy or passthrough mode in the mes configuration.

Currently you can’t configure granular MeshTrafficPermission policies for MeshExternalService resources. You can only enable or disable the whole traffic to MeshExternalService from a mesh. For more information, see Controlling MeshExternalService access from Mesh.

Configuration

The following sections describe the parameters you can configure in a MeshExternalService resource.

To use a MeshExternalService, you must enable a zone egress and mutual TLS.

Match

The match parameters specify the rules for matching traffic that will be routed to external resources defined in endpoints. The only type supported is HostnameGenerator (this field is optional). This means that Kong Mesh will match traffic directed to a hostname created by the HostnameGenerator resource. The port field is optional, when omitted, all traffic is matched. The protocols supported are: tcp, grpc, http, and http2.

match:
  type: HostnameGenerator
  port: 4244
  protocol: tcp

Endpoints

The endpoints parameters specify the destination of the matched traffic. You can define IPs, DNS names, and unix domain sockets.

endpoints:
  - address: 1.1.1.1
    port: 12345
  - address: example.com
    port: 80
  - address: unix:///tmp/example.sock

TLS

The tls parameters describe the TLS and verification behavior. TLS origination happens on the sidecar, so if your application is already using TLS you might want to use MeshPassthrough. You can define TLS version requirements, allow renegotiation, verification of the SNI, the SAN, the custom CA and the client certificate and key for server verification. To disable parts of the verification you can set a mode: SkipSAN, SkipCA, SkipAll, or Secured (default).

tls:
  version:
    min: TLS12
    max: TLS13
  allowRenegotiation: false
  verification:
    mode: SkipCA
    serverName: "example.com"
    subjectAltNames:
      - type: Exact
        value: example.com
      - type: Prefix
        value: "spiffe://example.local/ns/local"
    caCert:
      inline: dGVzdA==
    clientCert:
      secret: "123"
    clientKey:
      secret: "456"

When TLS is enabled but caCert is not set, the sidecar uses the auto-detected OS-specific CA. You can override the default CA by setting the path in the environment variable KUMA_DATAPLANE_RUNTIME_DYNAMIC_SYSTEM_CA_PATH for the sidecar.

DNS setup

Kong Mesh automatically creates a HostnameGenerator resource with a meshExternalService selector for each MeshExternalService resource created.

Once it’s created:

  • Kong Mesh generates a hostname based on the specified template, or multiple hostnames if there are multiple HostnameGenerators matching.
  • A VIP is allocated from the 242.0.0.0/8 range. This can be changed by KUMA_IPAM_MESH_EXTERNAL_SERVICE_CIDR environment variable.
  • An Envoy cluster is created and uses endpoints defined in spec.endpoints as the cluster endpoints.

Do not hijack original addresses. If you need to transparently pass traffic through the Mesh without modifying it, use MeshPassthrough.

For more information about accessing entire subdomains, see Wildcard DNS matching in MeshPassthrough.

Universal mode without transparent proxy

MeshExternalService works in Universal mode without transparent proxy, but you need to manually define an outbound that targets the correct MeshExternalService in the Dataplane configuration:

networking:
  outbound:
    - port: 8080
      backendRef:
        kind: MeshExternalService
        name: mes-http

Controlling MeshExternalService access from Mesh

Currently, you can’t configure a MeshTrafficPermission policy for a MeshExternalService resource. However, you can configure access to all external services on the mesh level. For example, you can disable outgoing traffic to all MeshExternalService resources:

Using MeshExternalService

In the following sections:

  • TCP examples use the https://tcpbin.com/ TCP echo service.
  • HTTP examples use the https://httpbin.konghq.com/ service for inspecting and debugging HTTP requests.
  • gRPC examples use the https://grpcbin.test.k6.io/ gRPC Request & Response Service. You can use grpcurl as a client, which is available in the netshoot debug image.

These examples use a single-zone deployment and the following HostnameGenerator:

In a multi-zone deployment, when applying resources on the global control plane, you need to:

  • Have a second HostnameGenerator with matchLabels: kuma.io/origin: global for resources applied on the global control plane.
  • Adjust the URLs accordingly to match the template.

TCP

This is a simple example of accessing tcpbin.com service without TLS that echoes back bytes sent to it:

Running the following command should print echo this in the terminal:

echo 'echo this' | nc -q 3 mes-tcp.svc.meshext.local 4242

TCP with TLS

This example builds up on the previous example adding TLS verification with default system CA. Notice that we’re using a TLS port 4243.

Running the following command should print echo this in the terminal:

echo 'echo this' | nc -q 3 mes-tcp-tls.svc.meshext.local 4243

TCP with mTLS

This example builds up on the previous example adding a client cert and key. Notice that we’re using an mTLS port 4244.

In a real-world scenario, you should use a secret and refer to it using its name instead of using inline.

Running the following command should print echo this in the terminal:

echo 'echo this' | nc -q 3 mes-tcp-mtls.svc.meshext.local 4244

HTTP

This is a simple example using plaintext HTTP:

Running the following command should print httpbin.konghq.com HTML in the terminal:

curl -s http://mes-http.svc.meshext.local

HTTPS

This example builds up on the previous example adding TLS verification with default system CA:

Running the following command should print httpbin.konghq.com HTML in the terminal:

curl http://mes-https.svc.meshext.local

gRPC

This is a simple example using plaintext gRPC:

Running the following command should print grpcbin.test.k6.io available methods:

grpcurl -plaintext -v mes-grpc.svc.meshext.local:9000 list

gRPCS

This example builds up on the previous example adding TLS verification with default system CA. Notice that we’re using a different port 9001.

Running the following command should print grpcbin.test.k6.io available methods:

grpcurl -plaintext -v mes-grpcs.svc.meshext.local:9001 list # this is using plaintext because Envoy is doing TLS origination

All policy configuration settings

FAQs

The main difference is that MeshExternalService assigns a custom domain and can be targeted by policies. MeshPassthrough doesn’t alter the address of the original host and can’t be targeted by policies.

Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!