Istio IP based Whitelisting
Tags: kubernetes, istio, devops, operations
Published: 2022-10-22 09:51:02

## 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](https://istio.io/) 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](https://istio.io/latest/docs/tasks/security/authorization/authz-ingress/#ip-based-allow-list-and-deny-list) of allowing/denying access based on IP list. It achieves it through **AuthorizationPolicy**. 

### Authorization Policy

Istio has provided a wonderful [documentation](https://istio.io/latest/docs/reference/config/security/authorization-policy/) 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_**.

![Istio IP based Whitelisting](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k8sqnr4i0154bdowttt2.png)

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: [](Image by <a href="https://pixabay.com/users/pixel2013-2364555/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=4031973">S. Hermann &amp;amp; F. Richter</a> from <a href="https://pixabay.com//?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=4031973">Pixabay</a>)