Enhancing Microservice Security with Istio

kubectl label namespace default istio-injection=enabled
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

Let’s see the list of productpage application containers:

kubectl -n default get pods productpage-v1-7df7cb7f86-ntwzz -o jsonpath="{.spec['containers','initContainers'][*].name}"
productpage 
istio-proxy 
istio-init

In addition to the productpage itself, sidecar istio-proxy (the same envoy) and init container istio-init work in the pod.

You can look at the pod’s iptables-rules configured in space using the nsenter utility. To do this, we need to find out the pid of the container process:

docker inspect k8s_productpage --format '{{ .State.Pid }}'
16286

Now we can see the iptables rules installed in this container.

It can be seen that almost all incoming and outgoing traffic is now intercepted and redirected to the ports on which envoy is already waiting for it.

Enable mutual traffic encryption

Policy and MeshPolicy objects were removed from istio 1.6. Instead, they suggest using the PeerAuthentication object.

Istio allows you to encrypt all traffic between containers, and the applications themselves will not even know that they communicate via tls. This is done by Istio himself out of the box with just one manifesto, since client certificates are already mounted in sidecar proxies.

The algorithm is as follows:

1. Envoy proxies on the client side and on the server side authenticate each other before sending requests;
2. If the check is successful, the client proxy encrypts the traffic and sends it to the server proxy;
3. The proxy server side decrypts the traffic and locally redirects it to the actual destination service.

You can enable mTLS at different levels:

• At the level of the entire network;
• At the namespace level;
• At the specific pod’s level.

Operating modes:

• PERMISSIVE: both encrypted and plain text traffic are allowed;
• STRICT: only TLS allowed;
• DISABLE: only plain text is allowed.

Let’s look at the details service from the pod’s productpage using curl without TLS enabled and see what comes to details using tcpdump:

Request:

Dump traffic:

All body and headings are perfectly readable in plain text.

Turn on tls. To do this, create an object of type PeerAuthentication in the namespace with our pod’s.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

Run the query from the product page to details again and see what you can get:

Traffic is encrypted

Login

ClusterRbacConfig, ServiceRole, and ServiceRoleBinding objects were removed along with the introduction of a new authorization policy. Instead, it is proposed to use the AuthorizationPolicy object.

Using authorization policies, Istio can configure one application to access another. Moreover, unlike pure Kubernetes network policies, this works at the L7 level. For example, for http traffic, you can finely control the methods and paths of the request.

As we saw in the previous example, by default access is open to all pods of the entire cluster.

Now we will ban all activities in the default namespace using this yaml file:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  {}

And try to get to the details service:

curl details:9080
RBAC: access denied

Great, now our request fails.

Now, let’s configure access so that only a GET request passes and only along the / details path, and all other requests are rejected. There are several options for this:

• You can configure that requests with specific headers pass;
• By the service account of the application;
• By outgoing ip-address;
• By outgoing namespace;
• According to claims in the JWT token.

The easiest to maintain is to configure access to the service account of the application, since no pre-configuration is required for this, since the bookinfo demo application already comes with service account created and mounted.

To use authorization policies based on service accounts, you must enable TLS mutual authentication.

Set up a new access policy:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "details-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: details
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/details/*"]

And try to reach out again:

root@productpage-v1-6b64c44d7c-2fpkc:/# curl details:9080/details/0
{"id":0,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"}

Everything is working. Let’s try other methods and ways:

root@productpage-v1-6b64c44d7c-2fpkc:/# curl -XPOST details:9080/details/0
RBAC: access denied
root@productpage-v1-6b64c44d7c-2fpkc:/# 
root@productpage-v1-6b64c44d7c-2fpkc:/# curl -XGET details:9080/ping
RBAC: access denied

Conclusion

In conclusion, I note that the opportunities considered are only a fraction of what Istio can do. Out of the box, we received and configured interservice traffic encryption and authorization, however, at the cost of adding additional components and, therefore, additional resource consumption.
Thanks to all!