Careful!
You are browsing documentation for a version of Kuma that is not the latest release.
Looking for even older versions? Learn more.
External Service
This policy allows services running inside the mesh to consume services that are not part of the mesh. The ExternalService
resource allows you to declare specific external resources by name within the mesh, instead of implementing the default passthrough mode. Passthrough mode allows access to any non-mesh host by specifying its domain name or IP address, without the ability to apply any traffic policies. The ExternalService
resource enables the same observability, security, and traffic manipulation for external traffic as for services entirely inside the mesh
When you enable this policy, you should also disable passthrough mode for the mesh and enable the data plane proxy builtin DNS name resolution.
Usage
A simple HTTPS external service can be defined:
apiVersion: kuma.io/v1alpha1
kind: ExternalService
mesh: default
metadata:
namespace: default
name: httpbin
spec:
tags:
kuma.io/service: httpbin
kuma.io/protocol: http
networking:
address: httpbin.org:443
tls: # optional
enabled: true
allowRenegotiation: false
sni: httpbin.org # optional
caCert: # one of inline, inlineString, secret
inline: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t... # Base64 encoded cert
clientCert: # one of inline, inlineString, secret
secret: clientCert
clientKey: # one of inline, inlineString, secret
secret: clientKey
Then apply the configuration with kubectl apply -f [..]
.
Accessing the External Service
Consuming the defined service from within the mesh for both Kubernetes and Universal deployments (assuming transparent proxy) can be done:
- With the
.mesh
naming of the servicecurl httpbin.mesh
. With this approach, specify port 80. - With the real name and port, in this case
curl httpbin.org:443
. This approach works only with the data plane proxy builtin DNS name resolution.
Although the external service is HTTPS, it’s consumed as plain HTTP. This is possible because when networking.tls.enabled
is set to true
then Envoy is responsible for originating and verifying TLS.
To consume the service using HTTPS, set the service protocol to kuma.io/protocol: tcp
and networking.tls.enabled=false
. This way application itself is responsible for originating and verifying TLS and Envoy is just passing the connection to a proper destination.
The first approach has an advantage that we can apply HTTP based policies, because Envoy is aware of HTTP protocol and can apply request modifications before the request is encrypted. Additionally, we can modify TLS certificates without restarting applications.
Available policy fields
tags
the external service can include an arbitrary number of tags, wherekuma.io/service
is mandatory. The specialkuma.io/protocol
tag is also taken into account and supports the standard Kuma protocol values. It designates the specific protocol for the service.- ` networking` describes the networking configuration of the external service
address
is the address where the external service can be reached.tls
is the section to configure the TLS originator when consuming the external serviceenabled
turns on and off the TLS origination.allowRenegotiation
turns on and off TLS renegotiation. It’s not recommended enabling this for security reasons. However, some servers require this setting to fetch client certificate after TLS handshake. TLS renegotiation is not available in TLS v1.3.sni
overrides the default Server Name Indication. Set this value to empty string to disable SNI.caCert
the CA certificate for the external service TLS verificationclientCert
the client certificate for mTLSclientKey
the client key for mTLS
As with other services, avoid duplicating service names under kuma.io/service
with already existing ones. A good practice is to derive the tag value from the domain name or IP of the actual external service.
← Proxy Template Retry →