Securing Microservices with Istio: First Steps

Guidelines for secure microservices configurations

Photo by Jamie Street on Unsplash

When working with microservices technology such as Kubernetes, we want to create a secure environment and communication between microservices. Sometimes, our projects need to grow up faster than others, and we forgot the security layer or its baselines to apply them in the first place. A similar story is for projects already in progress, in which we cannot implement significant changes because it’s challenging for the developers or architects to do.

Usually, the security configuration in microservices is one of the last steps to work and validate. So, our architecture could be attacked and compromised when we have insecure communication, authorization, and authentication between services. If our microservices are compromised, the attacker could access all services and information in our infrastructure. Thus, if we use a service mesh technology, we can apply a few features that could help us with the infrastructure, traffic management, and security tasks. With Istio Service Mesh, we have a friendly open-source technology to apply to our projects, which provides us with an efficient way to secure, connect, and monitor services.

In this article, we will discuss the following points:

• Istio Service Mesh: Brief explanation of what this is.
• PeerAuthentication, AuthorizationPolicy, RequestAuthentication: How to configure each feature.
• Conclusion: The outcome of this article.
• References: If you want to know more about this.

What is Istio Service Mesh?

Istio Service Mesh is a configurable infrastructure layer with low latency to manage a high volume of communications between application microservices using APIs. The Service Mesh provides critical capabilities such as service discovery, load balancing, encryption, authentication, authorization, traceability, circuit breaker, and more.

Istio control plane workflow

By default, Istio uses mTLS with authentication and authorization certificates to communicate services between them. This is a beneficial layer to create a zero-trust network.

The Istio security features provide a strong identity, robust policy, transparent TLS encryption, authentication, authorization, and audit (AAA) tools to protect your services and data. The goals of Istio security are:

• Security by default: the application code and infrastructure don’t need changes.
• Defense in depth: provide multiple layers of defense with existing security systems.
• Zero-trust network: could be used on distrusted networks building security solutions.

Istio security workflow

Istio Features

The Istio architecture has three main features: PeerAuthentication, RequestAuthentication and AuthorizationPolicy. It is recommended to configure these features after the deployment of the Istio system.

In the following image, we can check where these features can be used and how they all work. Each feature has a primary function to help us in the security workflow plan.

Istio features workflow

PeerAuthentication

In this feature, we will configure secure communication between services using HTTPS and TLS certificates. All pods without this configuration will not be available to use insecure protocols.

PeerAuthentication has two configurations to apply: strict mode and permissive mode. With the strict mode, you will use the mTLS layer only to create all communication with pods and use a secure channel to your cluster and infrastructure. We need to use the mtls section and add the strict label in the mode tag.

The following code explains how to apply this configuration:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
 name: "example-peer-policy_strict"
 namespace: example_1
spec:
 selector:
   matchLabels:
     app: reviews
 mtls:
   mode: STRICT

This way, if you need to use HTTP as a communication protocol between pods, the configuration to apply will be the same as strict but changing the properties to permissive label in mode tag in the mtls section.

The following code explains how to apply this configuration:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
 name: "example-peer-policy_permissive"
 namespace: example_1
spec:
 selector:
   matchLabels:
     app: webapp
 mtls:
   mode: PERMISSIVE

AuthorizationPolicy

In this configuration, you will set the restricted access and communication between services, specifying which service can communicate with other services. This configuration is important to keep other services safe and reduce the attack surface if any service has been compromised.

To allow the connections between two services, you need to add the action tag with the ALLOW option inside the spec section in the manifest and complete the destination services in the rules tag inside the same spec section. The following code explains how to apply this configuration:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "allow_call_catalog_from_webapp"
  namespace: example_2
spec:
  selector:
    matchLabels:
      app: webapp
  action: ALLOW
  rules:
  - to:
   - operation:
       path: ["*/api/catalog*"]

Istio Authorization policy example

In the previous example, the configuration allows the connection only between the web app and catalog services.

In another way, if you want to keep all connections closed in a service that could be dangerous or can generate an excessive load, you should use the deny option in action tag and add an empty rules tag. The following code explains how to apply this configuration:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "deny_all"
spec:
 action: DENY
 rules: {}

RequestAuthentication

This configuration will be working on user authentication and service authorization. This will validate authorized connections and actions only with the services allowed. To configure this rule to use JWKS (JSON Web Key Set), you need to generate the code with the Jwtrules parameters with two main labels: ISSUER and JWKURI. The Issuer will be the tag that contains the Token issuer information, and the jwtUri tag will expose the JWKS public server to validate the tokens. The following code explains how to apply this configuration:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: "example_jwt"
namespace: example_2
spec:
 selector:
   matchLabels:
     istio: ingressgateway
 Jwtrules:
 -issuer: ”test@istio.io”
  jwkUri: ”https://raw.githubusercontent.com/istio/istio/release-1.13/security/tools/jwt/samples/jwks.json”

Conclusions

With these three simple configurations, you can generate more integral and complete security to your microservice’s architecture, allowing it to be deployed in a Zero-trust network type. In addition, if you have a microservice compromised, we are limiting the possibilities of exploiting other microservices because the actions and communications between them are restricted, not allowing full access to all our microservices and clusters without restriction.

References

Istio Service Mesh is a powerful tool to use, so if you want to know more about it you can check the official Istio website.
Here you can check all the security benefits and options that Istio has and what you can do with it. Check it on Istio Security.
Some topics and info can be treated and checked on this book called Istio in action.
If you want to learn more about microservices and how it works, check the Kubernetes website.