3 Practical Way How to Restrict the Access to Our Load Balancer(NLB/ALB) on AWS EKS
Tags: aws, kubernetes, devops, tutorial
Published: 2020-05-28 06:14:05

![ALB AWS](https://dev-to-uploads.s3.amazonaws.com/i/85wlcflujl1ak40k0ubi.png)
In this article, I want to continue with how to restrict the access on our AWS Load Balancer(ALB/NLB). Since when we want our services(on container) can be accessed from the internet, we need to setup K8s services on EKS that usually will utilize AWS Load Balancer. 
To do this, We need to add several additional config like annotations on our K8S YAML for EKS Service. 
With this setup, only known traffic/network that we already authorize can access our services.

## Preparation
This article made with the purpose to complement the series. So, make sure you already read my previous articles in advance. 
read the series before to continue (or you already sure, you can follow the article) hence I will not talk the basics like initial setup on this article.

So, are you ready? , let's continue!

## Restrict with specific CIDR on ALB
The First way you can do for restricting the access is with open the access for specific CIDR only. CIDR itself is an acronym from Classless inter-domain routing that is known as a set of Internet protocol (IP) standards that are used to create unique identifiers for networks and individual devices. So, with restricting the access with CIDR, you can make sure only those domains network that you give the authorization can access the Load Balancer.

How to setup this for your ALB is with add annotation below on your YAML for ingress config
```
    alb.ingress.kubernetes.io/inbound-cidrs:x.x.x.x/x
```
Please be careful when setup because this annotation will be ignored if `alb.ingress.kubernetes.io/security-groups` is already specified.

## Restrict with SecurityGroup on ALB
The second way you can do is restrict using SecurityGroup. SecurityGroup is common way to configure the security on AWS. Since SecurityGroup can be integrated with the others, the best way to do it is you setup first and after the SecurityGroup is ready, we can start to use it on our config.

Below is the annotation you can use on your Ingress to specifies SecurityGroups you want to attach(SecurityGroup that you already configure before) at your Application LoadBalancer for EKS.
```
alb.ingress.kubernetes.io/security-groups: sg-xxx
```
You can also attach more than one security group like below
```
alb.ingress.kubernetes.io/security-groups: sg-xxxx, nameOfSg1, nameOfSg2
```

## Restrict with specific IP on NLB
If you only use simple service with `type:LoadBalancer` on EKS, we can be sure, you use NLB for your EKS to communicate with the outside world. 
Fortunately, with that setup, you can still restrict the access with specify the IP(Internet Protocol) that can access your Load Balancer. You can add the config below on `spec` section on your YAML.
```
  loadBalancerSourceRanges:
    - "x.x.x.x/x"
```
This is the full version will look like
```
---
apiVersion: v1
kind: Service
metadata:
  name: your-service-name
  labels:
    app: your-label-app
spec:
  loadBalancerSourceRanges:
    - "x.x.x.x/x"
  ports:
  - port: xx
    name: your-port-name
    targetPort: xx
  selector:
    app: your-app-Name
  type: LoadBalancer
```
you can also add more than one IP with this setup
```
  loadBalancerSourceRanges:
    - "x.x.x.x/x"
    - "y.y.y.y/y"
    - "z.z.z.z/z"
```
## Conclusion
As you can see on above, we have a lot of options(3 practical way) to restrict our Load Balancer when we integrate it with EKS. You can choose which way is the most suitable with your current situations.

I think that's it for now for this article comparison. Leave a comment below. So, I know about your thoughts! Thanks.