Outshift Logo

INSIGHTS

11 min read

Blog thumbnail
Published on 05/16/2023
Last updated on 04/12/2024

KubeClarity: Installation on AWS EKS architecture

Share

Lean Into Software Supply Chain Security with KubeClarity Series

https://github.com/openclarity/kubeclarity

The KubeClarity: Install and test drive article in our supply chain security 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. 

Let’s lean into the AWS EKS architecture and address how you can bolster your cloud security from the get-go. Gear up for a full walk-through of KubeClarity Installation on AWS EKS clusters.


Learn How to Install KubeClarity on AWS EKS

Figure-1: Learn How to Install KubeClarity on AWS EKS

 


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 the AWS EKS architecture

Note: 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 AWS 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 Amazon EKS architecture 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. We'll explore further details in this step show example references and output from my add-ons and IAM configurations.

Install AWS 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:

EKS Cluster Info and Configuration Options for Installation on AWS EKS

Figure-2: EKS Cluster Info and Configuration Options

Proceed to select add-ons and add them. The options are shown in Figure-3 below:

Configuring EKS Cluster Add-ons or Installation on AWS EKS

Figure-3: Configuring EKS Cluster Add-ons

Next, verify that the add-ons are installed and active, as seen in Figure-4 below:

List of Configured Add-Ons in EKS Cluster for Installation on AWS EKS

Figure-4: List of Configured Add-Ons in EKS Cluster

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 text

Example 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 the on AWS EKS architecture

To Install KubeClarity with Helm charts, you need to run these five steps:

helm repo add kubeclarity https://openclarity.github.io/kubeclarity
helm repo update 
helm show values kubeclarity/kubeclarity > values.yaml

Check 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 kubeclarity

Now 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 kubeclarity

You 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 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 kubeclarity

Verify 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 $KUBECLARITYIP

Now 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.  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.yaml

Check 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 have noticed 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:

KubeClarity UI Dashboard After a Fresh Install

Figure-5: KubeClarity UI Dashboard After a Fresh Install

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:

Navigating KubeClarity UI Dashboard for Starting a Run Time Scan

Figure-6: Navigating KubeClarity UI Dashboard for Starting a Run Time Scan

Next, select the newly installed sock-shop application namespace to start the scan by selecting the options as shown in Figure-7 below:

KubeClarity UI Dashboard Options to Start a Run Time Scan

Figure-7: KubeClarity UI Dashboard Options to Start a Run Time Scan

You can view the status of the ongoing scan as illustrated in Figure-8 below:

KubeClarity UI Dashboard Showing Scan Status

Figure-8: KubeClarity UI Dashboard Showing Scan Status

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.

KubeClarity UI Dashboard Showing Completed Scan Results

Figure-9: KubeClarity UI Dashboard Showing Completed Scan Results

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.

KubeClarity UI Dashboard Showing Application Vulnerabilities

Figure-10: KubeClarity UI Dashboard Showing Application Vulnerabilities

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.

KubeClarity UI  Summary Dashboard Showing Vulnerabilities

Figure-11: KubeClarity UI  Summary Dashboard Showing Vulnerabilities

The AWS EKS architecture in context

And with that, you're done! You have the KubeClarity Installation on the AWS EKS cluster alongside your business-critical applications. Want to learn more? Read up on AWS EKS made simple here at our blog.

Additionaly, 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 at Outshift, formerly Cisco’s Emerging Technology & Incubation organization.

Subscribe card background
Subscribe
Subscribe to
the Shift!

Get emerging insights on emerging technology straight to your inbox.

Unlocking Multi-Cloud Security: Panoptica's Graph-Based Approach

Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.

thumbnail
I
Subscribe
Subscribe
 to
the Shift
!
Get
emerging insights
on emerging technology straight to your inbox.

The Shift keeps you at the forefront of cloud native modern applications, application security, generative AI, quantum computing, and other groundbreaking innovations that are shaping the future of technology.

Outshift Background