Introduction

You might have seen Staff Only signboards in malls, restaurant and other public places. In general, while you are free to use or roam around public places, there are some place which only authorized entities are allowed, like kitchen in an restaurant.

Similarly while most of the services on the internet can be accessed by the public, there are some services which can only be accessed by Authorized users. Usually such services have sensitive information, breach in which might lead to application compromise or other devastating consequences.
It is therefore important to make sure that such services are secured to only authorized entity. One such measure is Whitelisting.

What is Istio

Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments

Whitelisting in Istio

Note: It is assumed that the reader has already setup Istio within the cluster.
Istio provides capability of allowing/denying access based on IP list. It achieves it through AuthorizationPolicy.

Authorization Policy

Istio has provided a wonderful documentation on Authorization Policy. I would highly recommend the reader to go through them for finer nuances. For our scenario, we will work with selector, rules and action.

At server side Envoy proxy, Istio through AuthorizationPolicy enforces allowing/denying access of inbound traffic. When a request comes to proxy, authorization engines, checks the incoming context against enforced policy and returns appropriate access as mentioned in the policy.

Implementing IP based Whitelisting using Authorization Policy

We can enforce multiple authorization checks, but in this example, we will restrict our policy to Whitelist only.

Suppose, you want to enforce Whitelist to path /my_critical_service to only a set of trusted IP (say xxx.xxx.xxx.xxx/y,aaa.aaa.aaa.aaa/b), we can achieve it by applying the below manifest. The below manifest will DENY all request to paths (/my_critical_service) which are not mentioned in the IP blocks list.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: <INSERT APPROPRIATE NAME>
 namespace: <INSERT NAMESPACE>
spec:
 selector:
   matchLabels:
     key_for_istio_metdata: value_for_istio_metadata
 action: DENY
 rules:
 - from:
   - source:
       notIpBlocks: ["xxx.xxx.xxx.xxx/y","aaa.aaa.aaa.aaa/b"]
   to:
   - operation:
       paths: ["/my_critical_service/*"]

Let's bisect to understand the above manifest.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: <INSERT APPROPRIATE NAME>
 namespace: <INSERT NAMESPACE>

Once Istio is setup, we can then use its CR, Authorization Policy. Assign appropriate metadata based on Istio installation.

spec:
 selector:
   matchLabels:
     key_for_istio_metdata: value_for_istio_metadata
 action: DENY
 rules:
 - from:
   - source:
       notIpBlocks: ["xxx.xxx.xxx.xxx/y","aaa.aaa.aaa.aaa/b"]
   to:
   - operation:
       paths: ["/my_critical_service/*"]

As mentioned earlier, Authorization Policy provides many options for enforcing policy checks, but for our task we have used selector, action and rules appropriately for IP based whitelisting.

• selector field is optional, which is used for selecting scope of our policy, i.e Target Workload where we want to enforce policy checking. Since we will be using Istio for Ingress, assign appropriate label key and values for identifying it.
• action field is used for enforcing appropriate action for set of rules. We can ALLOW or DENY request based on rules. For our task, we will DENY any request which is not matching our rules.

• rules field specifies list of criteria for actions to be enforced. We will be using from and to rules for our example.

• from rule, specifies the source of the request. We add trusted sources in notIpBlocks, so that we can DENY all request which are not trusted.

• to rule, specifies the operation of a request. In our scenario, we want to enforce whitelist for our my_critical_service path and so we provide appropriate path of our service within the rule.

And that's all. Now you can replace or add some of your own criteria to make your network secure!

Conclusion

We have seen in this blog, on how to enforce IP based whitelisting using Authorization Policy in Istio. Hope you found this blog helpful.

P.S: Cover Image Credit: S. Hermann & F. Richter from Pixabay