Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
11 min read
Published on 05/16/2023
Last updated on 02/05/2024
KubeClarity: Installation on AWS EKS
Share
The previous post in the series was about the easy installation of KubeClarity in your local Docker and Kubernetes environments. If you've tried KubeClarity and want to integrate it into your EKS cluster for serious cloud application scanning, this blog post is a perfect guide. Gear up for a full walk-through of KubeClarity Installation on AWS EKS clusters.
Fundamentally, the KubeClarity installation process via Helm charts remains the same regardless of whether installed on a KinD or EKS cluster. The main difference lies in the preliminary steps to ready the environment for installation. Assuming you already have a functioning EKS cluster, this post will guide you through the necessary prerequisites and installation process for KubeClarity on an EKS cluster. So, join the ride!
Step-0: Pre-requisites for KubeClarity Installation on AWS EKS
If your EKS cluster version is 1.23 or higher, proceed with this step. Otherwise, feel free to skip ahead to Step-1.
To install KubeClarity on an EKS cluster version 1.23 and higher, ensure you have included the necessary add-ons. For example, KubeClarity includes a PostgreSQL DB pod with volume bindings, necessitating the EBS CSI Driver add-on. You can learn about the add-ons here and see which ones you need for your deployments. The EBS CSI Driver add-on is necessary for KubeClarity installation on EKS 1.23 and higher.
Once installed, the EBS CSI Driver must be configured with IAMServiceRole and policies. Follow the instructions here to configure the CSI IAM Service Role and policies. If your deployment falls into this prerequisite criterion, and you have successfully configured the required add-ons and the supporting IAM roles, proceed straight to Step-1 below and skip further details in this section.
If you need additional guidance with installing and configuring the add-ons, stick around here. Further details in this step show example references and output from my add-ons and IAM configurations.
Install EKS Cluster Add-Ons
First, find and install the add-ons. From your AWS console, browse to your cluster to check your cluster info and config options as in Figure-2 below:
Proceed to select add-ons and add them. The options are shown in Figure-3 below:
Next, verify that the add-ons are installed and active, as seen in Figure-4 below:
This completes the installation of add-ons. Alternatively, you can also install add-ons via CLI. To do that, follow the instructions here.
Configure Add-ons
Now that we have the Add-ons installed and active, we need to ensure we configure the EBS CSI Driver Add-on with IAM Service Role.
The first step is to create an IAM OIDC provider for your cluster. Again, follow the link and choose either console or CLI options to configure. Be sure to provide your cluster name in the commands.
Next, run the below command and note the returned OIDC value because you will need to use that value to complete the configuration in the next steps. Again, replace your cluster name in the commands for “<cluster-name>.”
aws eks describe-cluster --name <cluster-name> --query
"cluster.identity.oidc.issuer" --output textExample output:
http://oidc.eks.us-west-1.amazonaws.com/id/<OIDC-value>Note: Make sure to use your own OIDC ID returned from running the above command. Also, plug in the region; in my case, it is “us-west-1". You must replace the values in ebs-csi-driver-trust-policy.json with your region and OIDC values.
Next, it is time to move on to CSI Driver IAMServiceRole creation. Follow the instructions here to configure the CSI IAM Service Role and policies.
Note: You don’t need a KMS encryption setup for KubeClarity install. KMS steps from the instructions can be safely skipped.
You have fulfilled all the prerequisites for the Installation on AWS EKS, and your cluster is ready for KubeClarity installation now.
Step-1: KubeClarity Installation on AWS EKS
To Install KubeClarity with Helm charts, you need to run these five steps:
helm repo add kubeclarity https://openclarity.github.io/kubeclarityhelm repo update helm show values kubeclarity/kubeclarity > values.yamlCheck the current configuration in values.yaml, And update the required values if needed. To enable and configure the supported SBOM generators and vulnerability scanners, check the "analyzer" and "scanner" config under the "vulnerability-scanner" section. You can skip changing the config and leave it on default settings.
helm install --values values.yaml --create-namespace kubeclarity kubeclarity/kubeclarity -n kubeclarityNow verify that KubeClarity pods are up and running and the installation has been completed. To do that, run the following command:
kubectl get pods -n kubeclarityYou should see four pods running in the kubeClarity namespace like below.
Here is an example output for your reference:
NAME READY STATUS RESTARTS AGE
kubeclarity-kubeclarity-7dbd967d4d-6b8bd 1/1 Running 0 9d
kubeclarity-kubeclarity-grype-server-d64c85c4-nbxn6 1/1 Running 0 15d
kubeclarity-kubeclarity-postgresql-0 1/1 Running 0 45h
kubeclarity-kubeclarity-sbom-db-7cfdc5bb55-58zl2 1/1 Running 0 9d
In my deployment, I prefer a load balancer front-ending my cluster. But it is completely optional. So, you can skip straight to Step-2 if you already have a load balancer configured or would like to skip this step. If you are interested, I’ll describe the load balancer configuration here.
Load Balancer Configuration (Optional)
Configure a load balancer for your EKS cluster and access the KubeClarity UI front end through it. This is an optional step, but given that most cloud applications are deployed behind a load balancer, it may be useful to know how to configure it. We must start with a config file to create a load balancer configuration. You can see an example of my config file below. Follow the instructions and create one on your end if you want to deploy a load balancer.
Create Config
cat > kube-apiclarity.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: lb-kubeclarity
labels:
app: kubeclarity-kubeclarity
spec:
selector:
app: kubeclarity-kubeclarity
type: LoadBalancer
ports:
- name: http
port: 8080
targetPort: 8080
protocol: TCP
EOF
Apply Config
kubectl apply -f lb-kubeclarity.yaml -n kubeclarityVerify Config
kubectl get svc -n kubeclarity
Example output is shown below:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubeclarity-kubeclarity ClusterIP 10.100.122.65 <none> 8080/TCP,8888/TCP 15d
kubeclarity-kubeclarity-grype-server ClusterIP 10.100.125.223 <none> 8080/TCP,9991/TCP 15d
kubeclarity-kubeclarity-postgresql ClusterIP 10.100.119.223 <none> 5432/TCP 15d
kubeclarity-kubeclarity-postgresql-hl ClusterIP None <none> 5432/TCP 15d
kubeclarity-kubeclarity-sbom-db ClusterIP 10.100.117.0 <none> 8081/TCP,8080/TCP 15d
lb-kubeclarity LoadBalancer 10.100.79.148 aef2916bf208e4893b5f4a75b453032f-1469671119.us-west-1.elb.amazonaws.com 8080:30166/TCP 15d
Next, to access the KubeClarity UI through the load balancer, run the following commands and note the KubeClarity IP.
export KUBECLARITYIP=$(kubectl get service -n kubeclarity lb-kubeclarity -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo $KUBECLARITYIPNow using this address http://<KUBECLARITYIP>:8080, you can fire up the KubeClarity UI. Be sure to replace your value with $KUBECLARITYIP.
Step-2: Sample Application Installation for Scanning (Optional)
We are going to install a sample sock shop microservice application. This is a completely optional step. So, you can either follow along and install this same app or install your own app. I’d recommend following my steps and installing the same app for beginners.
Create a namespace for the sock shop application we are about to install
kubectl create namespace sock-shop
Apply the manifest to install the sock shop
kubectl apply -f https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yamlCheck the status of pods in the sock-shop namespace
kubectl get pods -n sock-shop
The output looks like this:
NAME READY STATUS RESTARTS AGE
carts-5dc994cf5b-4rhfj 2/2 Running 0 44h
carts-db-556cbbd5fb-64qls 2/2 Running 0 44h
catalogue-b7b968c97-b9k8p 2/2 Running 0 44h
catalogue-db-f7547dd6-smzk2 2/2 Running 0 44h
front-end-848c97475d-b7sl8 2/2 Running 0 44h
orders-7d47794476-9fjsx 2/2 Running 0 44h
orders-db-bbfb8f8-7ndr6 2/2 Running 0 44h
payment-77bd4bbdf6-hkzh7 2/2 Running 0 44h
queue-master-6d4cf8c4ff-pzk68 2/2 Running 0 44h
rabbitmq-9dd69888f-6lzfh 3/3 Running 0 44h
session-db-7d9d77c495-zngsn 2/2 Running 0 44h
shipping-67fff9d476-t87jw 2/2 Running 0 44h
user-7b667cd8d-q8bg8 2/2 Running 0 44h
user-db-5599d45948-vxpq6 2/2 Running 0 44h
Step-3: Start Scan
Now that you have KubeClarity up and running and your custom application running in the same EKS cluster let’s run some scans.
As you may notice in the previous KinD-based installation, KubeClarity UI has no data to report vulnerabilities after a fresh install. The dashboard shows default values as in Figure-5 below:
Let’s start a run-time scan of the sock-shop application we installed and see what it finds. Choose the “Run Time Scan” option from the navigation bar on the left, as shown in Figure-6 below:
Next, select the newly installed sock-shop application namespace to start the scan by selecting the options as shown in Figure-7 below:
You can view the status of the ongoing scan as illustrated in Figure-8 below:
Step-4: Check the Results
Figure-9 shows the completed scan results, revealing a comprehensive report of affected components such as "Applications," "Application Resources," "Packages," and "Vulnerabilities." You can gather more information about the findings by clicking on each of these elements. For instance, I'm selecting "Applications" to review the specifics of the scan results. Here you can notice 14 applications in the sock shop namespace have been flagged with vulnerabilities.
Now, let's look at Figure-10 to delve into the details of the application findings from these 14 applications. The reported data includes useful details like the names of the impacted applications, the underlying packages and application resources impacted, the total number of vulnerabilities reported in each application, and many more useful details to explore.
We can also investigate the data related to application resources, packages, and vulnerabilities by returning to the dashboard displayed in Figure-9 and exploring further.
Alternatively, we can look at a summary view of the Dashboard by selecting the top left option in the navigation bar to see the summary view in the right-hand pane, as shown in Figure-11 below, and follow the findings from there. I leave it to you as an exercise.
Conclusion
And with that, you're done! You have the KubeClarity Installation on the AWS EKS cluster alongside your business-critical applications. Give KubeClarity a try and see what it detects in the sock shop app or take a more adventurous approach and scan your custom application within your preferred namespace. Keep in mind that you have the option to scan your entire cluster or specific namespaces with KubeClarity. Best of luck with your scanning, and let KubeClarity help you become a pro at finding vulnerabilities before they find you!
Next Up
Soon, you should fork the KubeClarity repo and enhance it for your needs. In preparation for forking and enhancing the KubeClarity repository, it would be helpful to delve into its nuts and bolts. So, let's gear up for a deep dive into the architecture next.
Pallavi Kalapatapu is a Principal Engineer and open-source advocate in Cisco’s Emerging Technology & Incubation organization.
Subscribe to
the Shift!
Get emerging insights on emerging technology straight to your inbox.
