Easy demo: Protect container traffic to EKS with BIG-IP

Intro

EKS (Elastic Kubernetes Service) is popular! It allows you to deploy apps without managing the Kubernetes mgmt plane yourself. If you're planning to run an app using EKS, you will likely need to consider ingress security along with that app. Securing traffic into Kubernetes is a topic we love to talk about at F5.

Why would you want a demo securing traffic into EKS?

It's fully automated! Since most people are new to Kubernetes (k8s for short), I find myself in need of a quick demo that's totally open for anyone to run. This way after I demo, the audience can go back to run it on their own, decompose it for themselves, and take their own time to understand it all.

Here's what we will automatically deploy:

Prerequisites

In short, you'll need an AWS demo account, a workstation with Terraform installed, your AWS creds configured, and the aws-iam-authenticator installed.

Here's a VM with all of your prerequisites:

If you don't have a workstation with Terraform installed, don't worry! You can easily set up the client workstation you need by deploying this demo workstation, which will have all the required tools. Then, configure your AWS IAM credentials.

Side note:

When building a cloud solution example, I try to stay as "vendor neutral" as practical and avoid using 3rd party tools when possible. For example, I have written a demo using AWS Lambda functions, instead of a 3rd party automation tool, for post-deployment configuration. This might be preferred if you do not (or cannot) use a particular 3rd party tool. So I originally started down the path of following this article to completely build an EKS demo via CFT. I planned to extend the quickstart demo to include an ingress controller and security policy, along with an app to protect. I guess I planned to use Lambda functions again. However, after talking about this with colleagues, the workarounds came to seem silly: nobody would do this in real life, so constraining myself to only using a CFT seemed unnecessary. Instead I chose to use the ubiquitous tool Terraform. This is easier to use and also saves me from requiring a user to have a few other tools, like kubectl, helm, and aws-iam-authenticator, etc. So, for better or worse, Terraform is a pre-req here. The workstation I've used is Ubuntu 18.04.

Now, for the demo

To deploy:

1. You'll need Terraform set up and your AWS credentials configured.
2. Optionally, deploy a demo workstation by following the ReadMe guide here.
3. Configure your AWS credentials in a demo account. Remember, this demo will deploy AWS resources that will cost you money via your AWS bill. Don't forget to destroy all resources at the end of your demo.
4. If you choose to skip this step, proceed with your own client workstation. But if you hit failures, I recommend using this demo workstation, since it is what I used when building this demo.
5. Connect to your workstation and run these commands. When prompted for confirmation, type "yes" as instructed.

git clone https://github.com/mikeoleary/aws-eks-bigip-terraform
cd aws-eks-bigip-terraform/vpc
terraform init
terraform plan
terraform apply

You've deployed! You will need to wait around 20 mins for everything to deploy: a VPC, EKS, a BIG-IP, and then an application in EKS to be protected by BIG-IP.

To see your finished product:

Once your Terraform commands have completed, you should see output values. If not, type this and take a note of the output values:

terraform output

Now, open a web browser and visit http://<public_ip_app>.

If you want to inspect the configuration of BIG-IP, visit https://<public_dns> and login with username admin and password <password>.

If you want to see the pods, service, or configmap running in EKS, run:

mkdir ~/.kube
terraform output kubeconfig > ~/.kube/config
kubectl describe po
kubectl describe svc
kubectl describe configmap

Don't stop here! Remember, you'll need to follow the steps to destroy your AWS resources, otherwise you'll be charged for running these AWS resources. Coincidentally you can use Terraform to limit this kind of rogue AWS spend, so don't be this guy:

Delete this demo

To destroy this demo in full, type:

terraform destroy

What just happened?

Let's review what just happened.

1. First, Terraform deployed a VPC and subnets, using the AWS provider.
2. Then, Terraform deployed some more resources in AWS:
3. an EKS cluster
4. an EC2 instance to be the k8s worker node
5. a BIG-IP VM
6. Then, Terraform deployed some resources to EKS using the Kubernetes provider:
7. a k8s deployment using the f5devcentral/helloworld image
8. a k8s service to expose this deployment
9. a k8s secret, a service account, and a cluster role binding, all to be used later in the helm deployment
10. a k8s configMap resource, which is read by CIS and populates a pool in a partition with IP addresses of pods in a given service.
11. Then, Terraform deployed F5 Container Ingress Services to k8s using the helm provider:
12. a helm chart that deploys F5 CIS using helm
13. the helm deployment was configured so that F5 CIS will point at the BIG-IP mgmt address, and use the secret generated earlier.

After all this, the components are all in place. We have an app in k8s that is exposed to ingress traffic, which is routed via the BIG-IP and automatically updated. Our app is protected!

Call to Action

To summarize:

1. Please use this demo to teach yourself and show your colleagues:
2. how critical it is to secure traffic into your container environment
3. how you can automate this process by using the tools you wish, and F5's extensive API's for automation.
4. Please leave me a note with feedback if you are able to use this demo. I would like it to be useful for you. Let me know how I can make it more useful, or feel free to contribute to the repo yourself. Thanks!