How To Secure Kubernetes deployments using Trivy-Operator

Cyberattacks penetrate Kubernetes clusters and containers by exploiting insecure code and weak network traffic flow security. Kubernetes applications must be scanned and audited to detect vulnerabilities that will give access to cyber attackers during a security breach. Applications that are running in the production stage in Kubernetes are called workloads. These workloads must be protected at all costs because their security and function performance determines the success of your brand.

We must assume that a data breach will occur tomorrow and implement all necessary security measures. Henceforth, Kubernetes workload scanners and auditors such as Trivy-Operator must be installed and used regularly to ensure that workload configuration manifests are secure before the workloads are deployed to the production stage. Kubernetes manifests either spell cluster disaster or success. Trivy-Operator is free and open source, and it is available across all three operating systems: Windows, macOS, and Linux, as a plugin.

In this article, you will learn different ways how to secure your workloads and learn how to install Trivy-Operator on Windows. Furthermore, you will learn how to audit your workloads using Trivy-Operator.

Prerequisites

You need kubectl and a running cluster.

How to Prevent Deployment Security Issues

The key to keeping a secure Kubernetes cluster is to think about the potential threats and implement security measures to mitigate those threats. This will help you keep your cluster safe from malicious users and hackers that might try to break into your cluster. A secure Kubernetes deployment starts with selecting secure hardware for the Kubernetes nodes. It would be best if you also secured the network communications to and from the cluster and the Kubernetes cluster itself. Here is a list of techniques you can use to deploy security issues:

1. Updating Kubernetes: Make sure your environment and infrastructure always uses the latest Kubernetes versions. These updates always contain critical security patches. Using old software versions puts you at risk of a security breach.

2. Not using containers escalated privileges: Create a different service account for your pods to add minimal privileges. The problem with the default service account is that it has more privileges that many pods and applications can access. This increases the security breach's impact as the attacker can access the host machine.

3. Securing images: Images are the beginning of the container lifecycle. A secure image gives your application more life, while insecure images give your container disaster. Insecure images are popular in public repositories. Vulnerabilities caused by third-party components are hard to find. It is imperative to only download official and trusted images from platforms such as Docker Hub and Artifact Hub. In addition, regularly scanning and auditing images is important to keep your deployments secure.

4. Policies are rules that banish inappropriate configurations and tasks. Implementing policies will automatically enable you to block pods that don't have the livenessProbe property. This property is very important as it tells the kubelet the state of your pod so it can execute necessary measures if the pod is dead.

5. Logs contain critical evidence that helps you catch security vulnerabilities. Regular log audits reveal malicious Kube API calls to your cluster. Setting up a logging management system will help you easily identify the root cause of the vulnerability.

6. Not setting the liveProbe and readinessProbe could lead to misconfigurations; because these two properties communicate the pod's health with the Kubelet, which is responsible for replacing dead pods. On the other side, the readinessProbe will tell you if the pod is ready to be deployed because it holds the status of the pod regarding when the pod is ready to make connections. Your app can face downtime if you deploy a pod without knowing its readiness status.

7. Resource limits are crucial components that make sure that your workloads are not starved of resources. Remember a resource-starved container will end up suffocating application tasks. The resources must be delegated fairly to ensure that all containers have enough resources. In addition, doing a load test during the production stages is important so that you know if your application will be able to serve all the customers and if it will be available most of the time. Load testing will also give you response time metrics using tools such as JMeter.

8. Encryption has proven to be one of the best ways of securing sensitive information over time. Over the years, cyberattackers cracked encryption algorithms, and cybersecurity experts responded by strengthening the encryption algorithm in terms of length and pattern. Only use the latest and strongest encryption, such as the Blowfish encryption algorithm, to encrypt your secrets.

How to Install Trivy-Operator Using Kubectl

Trivy-Operator can be installed on every operating system using Kubectl. Follow the instructions below to install the Trivy-Operator plugin.

Install Trivy-Operator plugin using Kubectl:

$ kubectl apply -f https://raw.githubusercontent.com/aquasecurity/trivy-operator/v0.1.9/deploy/static/trivy-operator.yaml

You will get the following output:

role.rbac.authorization.k8s.io/trivy-operator created
rolebinding.rbac.authorization.k8s.io/trivy-operator created
service/trivy-operator created

Check if the Trivy-Operator plugin has been installed successfully:

$ kubectl get deployment -n trivy-system

You will get the following output that shows that the Trivy-Operator plugin has been installed.

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
trivy-operator   1/1     1            1           2m3s

How to Assess Your Deployments Using Trivy-Operator

To test and see how the Trivy-Operator plugin works. Create a deployment resource that will be scanned using Trivy-Operator. Create a deployment.yaml file and add the following contents:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: boemo
      namespace: earthly
      labels:
        app: boemo-app
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: boemo-app
      template:
        metadata:
          labels:
            app: boemo-app
        spec:
          containers:
          - name: server
            image: nginx:1.17
            volumeMounts:
              - name: boemo-app
                mountPath: /usr/share/nginx/html
            ports:
            - containerPort: 80
              protocol: TCP
            resources:
              requests:
                cpu: 100m
                memory: "128M"
              limits:
                cpu: 100m
                memory: "256M"
            env:
            - name: LOG_LEVEL
              value: "DEBUG"
          volumes:
          - name: boemo-app
            configMap:
              name: boemo-app
              items:
              - key: body
                path: index.html

Use the following command to apply the above deployment:

    $ kubectl apply -f deployment.yaml

After creating the deployment resource, the Trivy-Operator plugin will detect the deployment automatically and create a configuration audit report. Trivy-Operator only scans workloads. Use the following command to list all detected and available configuration audit reports:

    $ kubectl get configauditreports -o wide

You will get the following output that shows available configuration reports. Since you created only one deployment earlier on, you will only see one configuration report called replicaset-boemo-59d4567b6b:

    NAME                                  SCANNER   AGE  CRITICAL HIGH  MEDIUM LOW
    replicaset-boemo-59d4567b6b   Trivy      11s          0            0            2        6

Use the following command to retrieve the configuration audit results for a specific workload:

    $ kubectl describe configauditreport replicaset-boemo-59d4567b6b

You will get the following output that gives you detailed configuration scan results. The results will specify the severity of the detected vulnerability. The classes of severity are:

• High
• Medium
• Low

All vulnerabilities classified as High must be resolved as soon as possible to prevent any flaws from causing chaos in the production environment. The Title field states the name of the detected vulnerability. The description field shows you what has to be done to resolve the detected vulnerability:

    Severity:     HIGH
        Success:      true
        Title:        Access to host network
        Category:     Kubernetes Security Check
        Check ID:     KSV003
        Description:  The container should drop all default capabilities and add only those that are needed for its execution.
        Messages:
          Container 'server' of ReplicaSet 'boemo-59d4567b6b' should add 'ALL' to 'securityContext.capabilities.drop'
        Severity:     LOW
        Success:      false
        Title:        Default capabilities not dropped
        Category:     Kubernetes Security Check
        Check ID:     KSV002
        Description:  A program inside the container can bypass AppArmor protection policies.
        Messages:

Learn More

To learn more about Trivy-Operator, see the project documentation.