CPLN Trivy

​

Overview

​

Architecture

• daemon (cron workload) — Runs on a configurable schedule, queries the registry for images that do not yet have a cpln/trivy-scan tag, and orchestrates scanning. Includes a trivy-api sidecar that wraps the Trivy CLI and returns HTML vulnerability reports.
• web-server (serverless workload) — Receives scan reports from the daemon, stores them in the configured storage backend, and serves them publicly via URL.

​

How the Two Workloads Talk

​

What Gets Created

• Cron Daemon Workload — Trivy daemon with trivy-api sidecar, runs on a cron schedule.
• Serverless Web-Server Workload — Report storage and serving, autoscales from 1–3 replicas.
• Identity & Policies — An identity carrying the AWS or Azure cloud-account binding for report storage, plus least-privilege policies: reveal on exactly the two prerequisite secrets, manage on images so scan tags can be written, and pull/view for the scanning service account.
• No credential secrets — The template creates no secrets of its own. Both the post token and the registry service account key live in secrets you create.

​

Prerequisites

​

Report Post Token

printf '%s' "$(openssl rand -hex 32)" | \
  cpln secret create-opaque --name my-cpln-trivy-post-token --encoding plain -f -

cpln secret reveal my-cpln-trivy-post-token -o yaml

​

Registry Service Account

printf '%s' 'your-service-account-key' | \
  cpln secret create-opaque --name trivy-credentials --encoding plain -f -

trivyAuth:
  secretName: trivy-credentials

cpln workload get-deployments web-server --gvc GVC_NAME -o yaml

The secret my-cpln-trivy-post-token no longer exists. Workload updates are
paused until the secret is added or the reference to the secret removed.

​

Storage

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ]
        }
    ]
}

​

Configuration

# Storage backend for vulnerability reports. Options: "s3" or "azureFileshare"
storage:
  type: s3

  s3:
    cloudAccountName: my-aws-cloud-account # AWS cloud account name registered in Control Plane
    bucket: trivy-reports-bucket           # S3 bucket name
    region: us-east-1                      # AWS region
    policyName: my-trivy-s3-policy         # IAM policy scoped to the bucket (see Prerequisites)

  azureFileshare:
    cloudAccountName: my-azure-cloud-account
    accountName: mystorageaccount
    fileShare: trivy-reports
    scope: "" # /subscriptions/<id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<name>

# Bearer token the daemon presents when posting reports to the web-server.
# Name of a pre-existing CPLN opaque secret whose payload is the token (see Prerequisites).
postToken:
  secretName: my-cpln-trivy-post-token

# Authentication for Trivy to pull images from the Control Plane image registry.
# Name of a pre-existing CPLN opaque secret whose payload is the service account key (see Prerequisites).
trivyAuth:
  secretName: trivy-credentials

# Control Plane service account that Trivy uses to pull images (see Prerequisites)
serviceAccountName: trivy-service-account

# Cron schedule for the scanning daemon
schedule: "*/59 * * * *"

# Rescan images whose last scan is older than this (e.g. "7d", "24h"). Empty = scan once only.
rescanAfter: 7d

daemon:
  image: ghcr.io/controlplane-com/cpln-trivy-daemon:1.2.0
  resources:
    cpu: 1
    memory: 1Gi
  firewall:
    outboundAllowCIDR:
      - 0.0.0.0/0

trivyApi:
  image: ghcr.io/controlplane-com/cpln-trivy-trivy-api:1.2.0
  resources:
    cpu: 2
    memory: 4Gi

webServer:
  image: ghcr.io/controlplane-com/cpln-trivy-web-server:1.2.0
  resources:
    cpu: 150m
    memory: 128Mi
  autoscaling:
    minScale: 1
    maxScale: 3
  firewall:
    inboundAllowCIDR:
      - 0.0.0.0/0
    outboundAllowCIDR:
      - 0.0.0.0/0

​

Configuration Reference

​

Upgrading From 1.1.0

cpln-trivy: postToken is no longer a plain value in 1.2.0. Put the token in an opaque secret
(encoding: plain) and set postToken.secretName to its name. Reuse the SAME token your install
already has, or the daemon's uploads start returning 401.

​

Rotating the Token Later

​

Viewing Reports

cpln image query --tag cpln/trivy-scan --max -1 -o json | jq '.items[].name'

​

Maintenance

​

Periodic Re-Scans

​

Force an Immediate Re-Scan

cpln image tag my-image:latest --remove cpln/trivy-scan --remove cpln/trivy-scan-time

cpln image query --tag cpln/trivy-scan --max -1 -o json | jq -r '.items[].name' | \
  xargs -I{} cpln image tag {} --remove cpln/trivy-scan --remove cpln/trivy-scan-time

​

Important Notes

• Create both prerequisite secrets before installing. A missing one wedges the deployment with no log output at all; Prerequisites gives the one command that diagnoses it.
• A scan touches every image in the organization, not just images this install created — see the warning in Overview.
• Rotating the post token requires restarting both workloads together — see Rotating the Token Later.
• Report reads are unauthenticated. Anyone with the URL can open a report.
• Scans take roughly 15–20 seconds per image — about 30 minutes for 100 images on a first run. Overlapping runs are prevented, so a long run simply delays the next scheduled one.
• Rescans overwrite in place — the report keeps its URL and cpln/trivy-scan-time is refreshed, so links saved from the console stay valid.
• Rotate the service account key by adding a new key, updating the opaque secret’s payload, then deleting the old key. No reinstall needed.
• The workloads are named daemon and web-server regardless of release name — install this template only once per GVC.

​

External References