CODEWITHSUNDEEP
istioenvoyproxy
letthefireflieslive
letthefireflieslive

Reputation: 12684

How to communicate securely to a k8s service via istio?

I can communicate to another service in the same namespace via:

curl http://myservice1:8080/actuator/info

inside the pod.

The application is not configured with TLS, I am curious if I can reach that pod via virtual service so that I can utilized this Istio feature:

curl https://myservice1:8080/actuator/info

We have Istio virtualservice and gateway in place. External access to pod is managed by it and is working properly. We just wanted to reach another pod via https if possible without having to reconfigure the application.

Upvotes: 1

Views: 52

Answers (1)

Mikołaj Głodziak
Mikołaj Głodziak

Reputation: 5277

How to communicate securely to a k8s service via istio?

Answering the question under the title - there will be many possibilities, but you should at the beginning Understanding TLS Configuration:

One of Istio’s most important features is the ability to lock down and secure network traffic to, from, and within the mesh. However, configuring TLS settings can be confusing and a common source of misconfiguration. This document attempts to explain the various connections involved when sending requests in Istio and how their associated TLS settings are configured. Refer to TLS configuration mistakes for a summary of some the most common TLS configuration problems.

There are many different ways to secure your connection. It all depends on what exactly you need and what you set up.

We have istio virtualservice and gateway in place, external access to pod is managed by it and working properly. We just wanted to reach another pod via https if possible without having to reconfigure the application

As for virtualservice and gateway, you will find an example configuration in this article. You can find guides for single host and for multiple hosts.

We just wanted to reach another pod via https if possible without having to reconfigure the application.

Here you will most likely be able to apply the outbound configuration:

While the inbound side configures what type of traffic to expect and how to process it, the outbound configuration controls what type of traffic the gateway will send. This is configured by the TLS settings in a DestinationRule, just like external outbound traffic from sidecars, or auto mTLS by default.

The only difference is that you should be careful to consider the Gateway settings when configuring this. For example, if the Gateway is configured with TLS PASSTHROUGH while the DestinationRule configures TLS origination, you will end up with double encryption. This works, but is often not the desired behavior.

A VirtualService bound to the gateway needs care as well to ensure it is consistent with the Gateway definition.

Upvotes: 1

Related Questions