Image security scanning in Kubernetes - Commands & Configuration

Introduction

Image security scanning checks container images for vulnerabilities before running them. It helps prevent security risks by finding weak spots early.

When you want to ensure your container images do not have known security issues before deployment

When you need to comply with company security policies for container usage

When you want to automate vulnerability checks in your CI/CD pipeline

When you want to avoid running containers with outdated or unsafe software

When you want to get reports on image risks to decide if an update is needed

Config File - trivy-config.yaml

trivy-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: trivy-config
  namespace: default
data:
  TRIVY_SEVERITY: "CRITICAL,HIGH"
  TRIVY_IGNORE_UNFIXED: "true"
  TRIVY_TIMEOUT: "5m"

This ConfigMap sets up Trivy scanner options:

• TRIVY_SEVERITY: Only report critical and high severity issues.
• TRIVY_IGNORE_UNFIXED: Ignore vulnerabilities without fixes yet.
• TRIVY_TIMEOUT: Limit scan time to 5 minutes.

Commands

Create a ConfigMap in Kubernetes to store Trivy scanner settings for severity, ignoring unfixed issues, and timeout.

Terminal

kubectl create configmap trivy-config --from-literal=TRIVY_SEVERITY=CRITICAL,HIGH --from-literal=TRIVY_IGNORE_UNFIXED=true --from-literal=TRIVY_TIMEOUT=5m

Expected Output

configmap/trivy-config created

→

--from-literal - Add key-value pairs directly to the ConfigMap

Run Trivy to scan the nginx:1.23 container image for critical and high severity vulnerabilities, ignoring unfixed ones, with a 5-minute timeout.

Terminal

trivy image --severity CRITICAL,HIGH --ignore-unfixed --timeout 5m nginx:1.23

Expected Output

2024-06-01T12:00:00.000Z	INFO	Detected OS: debian

2024-06-01T12:00:00.500Z	INFO	Number of vulnerabilities: 2

nginx:1.23 (debian 11.6)



+------------------+------------------+----------+-------------------+---------------+--------------------------------+

|  LIBRARY         | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE                          |

+------------------+------------------+----------+-------------------+---------------+--------------------------------+

| libssl1.1        | CVE-2023-12345   | CRITICAL | 1.1.1d-0+deb11u3  | 1.1.1d-0+deb11u4 | OpenSSL vulnerability          |

| curl             | CVE-2023-67890   | HIGH     | 7.74.0-1.3+deb11u1| 7.74.0-1.3+deb11u2| Curl security issue            |

+------------------+------------------+----------+-------------------+---------------+--------------------------------+

→

--severity - Filter vulnerabilities by severity level

→

--ignore-unfixed - Skip vulnerabilities without fixes

→

--timeout - Set maximum scan duration

Run Trivy scanner as a temporary Kubernetes pod to scan the nginx:1.23 image with the same options, then remove the pod after completion.

Terminal

kubectl run trivy-scan --image=aquasec/trivy:latest --restart=Never --rm -it -- trivy image nginx:1.23 --severity CRITICAL,HIGH --ignore-unfixed --timeout 5m

Expected Output

Pod/trivy-scan created

2024-06-01T12:01:00.000Z	INFO	Detected OS: debian

2024-06-01T12:01:00.500Z	INFO	Number of vulnerabilities: 2

nginx:1.23 (debian 11.6)



+------------------+------------------+----------+-------------------+---------------+--------------------------------+

|  LIBRARY         | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE                          |

+------------------+------------------+----------+-------------------+---------------+--------------------------------+

| libssl1.1        | CVE-2023-12345   | CRITICAL | 1.1.1d-0+deb11u3  | 1.1.1d-0+deb11u4 | OpenSSL vulnerability          |

| curl             | CVE-2023-67890   | HIGH     | 7.74.0-1.3+deb11u1| 7.74.0-1.3+deb11u2| Curl security issue            |

+------------------+------------------+----------+-------------------+---------------+--------------------------------+

Pod/trivy-scan deleted

→

--restart=Never - Run pod only once without restarting

→

--rm - Remove pod after it finishes

→

-it - Run interactively to see output

Key Concept

If you remember nothing else from this pattern, remember: scanning container images for vulnerabilities before deployment helps prevent security risks in your applications.

Common Mistakes

Running image scans without specifying severity filters

This can produce too many low-risk findings, making it hard to focus on critical issues

Use severity flags like --severity CRITICAL,HIGH to focus on important vulnerabilities

Not setting a timeout for scans

Scans can hang or take too long, blocking automation pipelines

Use --timeout flag to limit scan duration and keep pipelines fast

Running scans outside Kubernetes when you want cluster integration

You miss benefits of running scans as pods with cluster access and config management

Run scanners as Kubernetes pods using kubectl run with proper flags

Summary

Create a ConfigMap to store scanner settings for severity and timeout.

Run Trivy CLI to scan container images for critical and high vulnerabilities.

Use kubectl run to scan images inside Kubernetes pods for better integration.

Practice

1. What is the main purpose of image security scanning in Kubernetes?

easy

A. To find vulnerabilities in container images before deployment

B. To increase the size of container images

C. To speed up the container startup time

D. To monitor network traffic between containers

Solution

1. Step 1: Understand image security scanning

   Image security scanning checks container images for security issues like vulnerabilities.

2. Step 2: Identify the main goal

   The goal is to find and fix vulnerabilities before deploying containers to keep apps safe.

3. Final Answer:

   To find vulnerabilities in container images before deployment -> Option A

4. Quick Check:

   Image scanning = find vulnerabilities [OK]

Hint: Image scanning finds security holes before use [OK]

Common Mistakes:

• Confusing scanning with performance tuning
• Thinking it monitors network traffic
• Believing it changes image size

2. Which command correctly scans a Docker image named myapp:latest using Trivy?

easy

A. trivy myapp:latest scan

B. trivy scan myapp:latest

C. trivy image myapp:latest

D. trivy scan image myapp

Solution

1. Step 1: Recall Trivy scan syntax

   The correct command to scan an image is trivy image <image-name>.

2. Step 2: Match the command with options

   trivy image myapp:latest matches the correct syntax exactly.

3. Final Answer:

   trivy image myapp:latest -> Option C

4. Quick Check:

   Trivy scan command = trivy image [OK]

Hint: Use 'trivy image' to scan images [OK]

Common Mistakes:

• Using 'trivy scan' instead of 'trivy image'
• Placing 'scan' after image name
• Omitting the 'image' keyword

3. What will be the output of the command trivy image alpine:3.15 if the image has no vulnerabilities?

medium

A. No vulnerabilities detected, image is safe

B. Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

C. Error: image not found

D. Vulnerabilities found: 0

Solution

1. Step 1: Understand Trivy output for clean images

   When no vulnerabilities are found, Trivy outputs a table ending with Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0).

2. Step 2: Compare options with expected output

   Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0) matches the typical Trivy message for no vulnerabilities.

3. Final Answer:

   Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0) -> Option B

4. Quick Check:

   No vulnerabilities message = Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0) [OK]

Hint: Look for 'Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)' in scan output [OK]

Common Mistakes:

• Expecting a numeric count output
• Confusing error messages with success
• Assuming 'no vulnerabilities' means error

4. You run trivy image myapp:latest but get an error: ERROR: unable to find image. What is the likely cause?

medium

A. The image name is misspelled or does not exist locally

B. Trivy is not installed correctly

C. The Kubernetes cluster is down

D. The Docker daemon is running

Solution

1. Step 1: Analyze the error message

   The error 'unable to find image' means Trivy cannot locate the specified image locally or remotely.

2. Step 2: Identify common causes

   Most often, this happens if the image name is wrong or the image is not pulled yet.

3. Final Answer:

   The image name is misspelled or does not exist locally -> Option A

4. Quick Check:

   Image not found error = wrong image name [OK]

Hint: Check image name spelling and availability [OK]

Common Mistakes:

• Blaming Kubernetes cluster status
• Assuming Trivy installation issue
• Ignoring image presence locally

5. You want to automate image scanning in your Kubernetes CI/CD pipeline using Trivy. Which approach is best to ensure images are scanned before deployment?

hard

A. Only scan images once a month regardless of deployment

B. Scan images manually after deployment to production

C. Ignore scanning if images come from trusted sources

D. Add a pipeline step that runs trivy image <image> and fails if vulnerabilities are found

Solution

1. Step 1: Understand CI/CD pipeline best practices

   Automated scanning before deployment helps catch vulnerabilities early and prevents unsafe images from running.

2. Step 2: Evaluate options for automation

   Add a pipeline step that runs trivy image <image> and fails if vulnerabilities are found. This integrates scanning into the pipeline and blocks deployment if issues exist, which is best practice.

3. Final Answer:

   Add a pipeline step that runs trivy image <image> and fails if vulnerabilities are found -> Option D

4. Quick Check:

   Automate scanning pre-deployment = Add a pipeline step that runs trivy image <image> and fails if vulnerabilities are found [OK]

Hint: Scan images in pipeline and fail on vulnerabilities [OK]

Common Mistakes:

• Scanning only after deployment
• Ignoring scans for trusted images
• Scanning too infrequently