logo
Alauda DevOps Pipelines Docs
logo
Alauda DevOps Pipelines Docs
Navigation

Overview

Introduction
Architecture
Feature Overview
Quick Start
Lifecycle Policy
Release Notes

Concepts

TektonConfig
TektonPipeline
Install

Upgrade

Upgrade Path
Upgrade Alauda DevOps Pipelines Operator

Configure

Adjusting Optional Configuration Items of Subcomponents
Configuring Resource Quotas for Pipeline Components
Pod Template Configuration Guide
Regular Cleanup of TaskRun and PipelineRun Resources

How To

Deploying tekton-pipelines in a global cluster through TektonConfig

Pipelines

Introduction
Architecture

Concepts

Tasks
TaskRuns
Pipelines
PipelineRuns
StepActions
Resolvers
Workspaces
Pod Templates
Quick Start

How To

Adjust Dockerfile for Building Task-Compatible Custom Images
Specifying remote pipelines using hub resolvers
Specifying remote tasks using hub resolvers
Use java-image-build-scan-deploy Pipeline

Trouble Shooting

Failed to create pod due to config error when using custom images in Tekton
Permission Issues When Using Custom Images in run-script Task
Unable to Use Multiple PVC Workspaces in Tekton
permissions

Triggers

Introduction
Architecture

Core Concepts

Core Concepts
EventListener
Trigger
Interceptor
TriggerBinding
TriggerTemplate
Quick Start

How To

Setup EventListener
Use GitLab Event Triggers
Create TriggerTemplate

Troubleshooting

The Pipeline is not automatically triggered
Permission Description

Hub

Introduction
Architecture

Core Concepts

Concepts
Understanding Tekton Hub
Permission Description

Results

Introduction
Architecture

Concepts

Core Concepts
Tekton Results
Quick Start
permissions

Configure

Database Configuration

Supply Chain Security

Introduction
Architecture

Concepts

Core Concepts
Understanding Tekton Chains

Quick Start

Getting Started
Signed Provenance

How To

Image Signature Verification
Build System Provenance Verification
Source Code Repository Verification
Vulnerability Scanning and Verification
Base Image and SBOM Verification
License Compliance Verification
Keyless Signing Verification

Configure

Chains Configuration
Chains Configuration
Authentication for Chains
Signing Key Configuration

API Reference

Introduction

Kubernetes APIs

Pipelines

Pipeline [tekton.dev/v1]
Task [tekton.dev/v1]
PipelineRun [tekton.dev/v1]
TaskRun [tekton.dev/v1]
ClusterTask [tekton.dev/v1]
Run [tekton.dev/v1]
CustomRun [tekton.dev/v1]
StepAction [tekton.dev/v1]
VerificationPolicy [tekton.dev/v1alpha1]
ResolutionRequest [resolution.tekton.dev/v1beta1]

Triggers

Trigger [triggers.tekton.dev/v1beta1]
TriggerTemplate [triggers.tekton.dev/v1beta1]
EventListener [triggers.tekton.dev/v1beta1]
TriggerBinding [triggers.tekton.dev/v1beta1]
Interceptor [triggers.tekton.dev/v1alpha1]
ClusterTriggerBinding [triggers.tekton.dev/v1beta1]
ClusterInterceptor [triggers.tekton.dev/v1alpha1]

Operator

TektonConfig [operator.tekton.dev/v1alpha1]
TektonInstallerSet [operator.tekton.dev/v1alpha1]
TektonPipeline [operator.tekton.dev/v1alpha1]
TektonTrigger [operator.tekton.dev/v1alpha1]
TektonChain [operator.tekton.dev/v1alpha1]
TektonHub [operator.tekton.dev/v1alpha1]
TektonResult [operator.tekton.dev/v1alpha1]
TektonInstallerSet [operator.tekton.dev/v1alpha1]
OpenShift Pipelines as Code [operator.tekton.dev/v1alpha1]

Advanced APIs

Results

Introduction to API Usage
Results List
Results Details
Result records List
Result logs List
📝 Edit this page on GitHub
Previous PageBase Image and SBOM Verification
Next PageKeyless Signing Verification

#License Compliance Verification

In ACP (Alauda Container Platform), you can use trivy or syft task in Tekton Pipeline to generate the SBOM for image.

The SBOM contains license information for each component in the image. We can use Kyverno policies to reject images that include specific licenses.

Since the SBOM has been generated for the image in Base Image and SBOM Verification, we will not create a pipeline here, but directly use the existing image to verify this capability.

TIP

This chapter is based on Base Image and SBOM Verification, only adds the logic to validate the license information of the image.

#TOC

#Feature Overview

This method is similar to Base Image and SBOM Verification, only change the kyverno rules to verify the license compliance.

  1. Configure Kyverno rules to verify the SBOM.
  2. Use the image to create a Pod to verify the license compliance.

#Use Cases

The following scenarios require referring to the guidance in this document:

  • Implementing license compliance verification in Kubernetes clusters using Kyverno
  • Enforcing security policies to block images containing specific licenses (e.g., GPL)
  • Setting up automated license verification in CI/CD pipelines
  • Ensuring license compliance in production environments
  • Implementing supply chain security controls for container images by verifying their component licenses

#Prerequisites

  • Base Image and SBOM Verification is completed.

#Process Overview

StepOperationDescription
1Verify license informationCreate and apply Kyverno policy to verify component licenses
2(Optional) Verify CVE checkAdd conditions to check specific vulnerabilities in the policy
3Clean upDelete test resources and policies

#Step-by-Step Instructions

#Steps 1: Verify the license information of the image

#Step 1.1: Create a Kyverno policy to verify the base image information

TIP

This step requires cluster administrator privileges.

More details about Kyverno ClusterPolicy, please refer to Kyverno ClusterPolicy

The policy is as follows:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-component-licenses
spec:
  webhookConfiguration:
    failurePolicy: Fail
    timeoutSeconds: 30
  background: false
  rules:
    - name: check-image
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - policy
      verifyImages:
        - imageReferences:
            - "*"
            # - "<registry>/test/*"
          skipImageReferences:
            - "ghcr.io/trusted/*"
          failureAction: Enforce
          verifyDigest: false
          required: false
          useCache: false
          imageRegistryCredentials:
            allowInsecureRegistry: true
            secrets:
              # The credential needs to exist in the namespace where kyverno is deployed
              - registry-credentials

          attestations:
            - type: https://cyclonedx.org/bom
              attestors:
                - entries:
                    - attestor:
                      keys:
                        publicKeys: |- # <- The public key of the signer
                          -----BEGIN PUBLIC KEY-----
                          MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFZNGfYwn7+b4uSdEYLKjxWi3xtP3
                          UkR8hQvGrG25r0Ikoq0hI3/tr0m7ecvfM75TKh5jGAlLKSZUJpmCGaTToQ==
                          -----END PUBLIC KEY-----

                        ctlog:
                          ignoreSCT: true

                        rekor:
                          ignoreTlog: true

              conditions:
                - any:
                    # Check if the image contains specific licenses
                    - key: "{{ components[].licenses[].license.id }}"
                      operator: AllNotIn
                      value: ["GPL-3.0-only", "GPL-3.0-or-later"]
                      message: |
                        The image contains GPL licenses which are not allowed.
                        Found licenses: {{ components[].licenses[].license.id }}

                    # Check if the image contains specific license names
                    - key: "{{ components[].licenses[].license.name }}"
                      operator: AllNotIn
                      value: ["GPL"]
                      message: |
                        The image contains Expat license which is not allowed.
                        Found licenses: {{ components[].licenses[].license.name }}
Explanation of YAML fields
  • The policy is largely consistent with the one in Image Signature Verification
  • spec.rules[0].verifyImages[].attestations[0].conditions
    • type: The cyclonedx SBOM attestation type is https://cyclonedx.org/bom
    • attestors: the same as above.
    • conditions: The conditions to be verified.
      • any: Any of the conditions must be met.
        • key: "{{ components[].licenses[].license.id }}": The image contains GPL licenses which are not allowed.
        • key: "{{ components[].licenses[].license.name }}": The image contains Expat license which is not allowed.

Save the policy to a yaml file named kyverno.verify-component-licenses.yaml and apply it with:

$ kubectl create -f kyverno.verify-component-licenses.yaml

clusterpolicy.kyverno.io/verify-component-licenses created

#Step 1.2: Verify the policy

In the policy namespace where the policy is defined, create a Pod to verify the policy.

Use the built image to create a Pod.

$ export NAMESPACE=<policy>
$ export IMAGE=<<registry>/test/chains/demo-5:latest@sha256:a6c727554be7f9496e413a789663060cd2e62b3be083954188470a94b66239c7>

$ kubectl run -n $NAMESPACE component-licenses --image=${IMAGE} -- sleep 3600

If your image contains GPL licenses, the Pod will be created failed.

Receive the output like this:

Error from server: admission webhook "mutate.kyverno.svc-fail" denied the request:

resource Pod/policy/high-risk was blocked due to the following policies

verify-component-licenses:
  check-image: |
    image attestations verification failed, verifiedCount: 0, requiredCount: 1, error: .attestations[0].attestors[0].entries[0].keys: attestation checks failed for <registry>/test/chains/demo-5:latest and predicate https://cyclonedx.org/bom: The image contains GPL licenses which are not allowed.
    Found licenses: ["GPL-3.0-only","GPL-3.0-or-later","Latex2e"]
    ; The image contains Expat license which is not allowed.
    Found licenses: [,"GPL","LGPL","public-domain"]

Change the license limit in the ClusterPolicy to allow GPL licenses.

conditions:
  - any:
    - key: "{{ components[].licenses[].license.id }}"
      operator: AllNotIn
      value: ["GPL-8.0-only"]
      message: |
        The image contains GPL licenses which are not allowed.
        Found licenses: {{ components[].licenses[].license.id }}

    - key: "{{ components[].licenses[].license.name }}"
      operator: AllNotIn
      value: ["GPL-x"]
      message: |
        The image contains Expat license which is not allowed.
        Found licenses: {{ components[].licenses[].license.name }}

Then create a Pod to verify the policy.

$ kubectl run -n $NAMESPACE component-licenses --image=${IMAGE} -- sleep 3600

pod/component-licenses created

The Pod will be created successfully.

#Step 2: (Optional) Verify Image Check CVE-2022-42889

TIP
  • If you interested to add more conditions to the policy, you can continue to read the following content.
  • This is a simple example, you can use the same method to check other vulnerabilities.

CVE-2022-42889 is a critical vulnerability in the Apache Commons Text library which could lead to arbitrary code executions and occurs in versions 1.5 through 1.9. Detecting the affected package may be done in an SBOM by identifying the "commons-text" package with one of the affected versions. This policy checks attested SBOMs in CycloneDX format of an image specified under imageReferences and denies it if it contains versions 1.5-1.9 of the commons-text package.

We only need to add a condition to the ClusterPolicy to check if the commons-text package is in the image.

conditions:
  - all:
    - key: "{{ components[?name=='commons-text'].version || 'none' }}"
      operator: AllNotIn
      value: ["1.5","1.6","1.7","1.8","1.9"]

This is not demonstrated here, interested readers can try it themselves.

#Step 3: Clean up the resources

Delete the Pods created in the previous steps.

$ export NAMESPACE=<policy>
$ kubectl delete pod -n $NAMESPACE component-licenses

Delete the policy.

$ kubectl delete clusterpolicy verify-component-licenses

#Expected Results

After completing this guide:

  • You have a working setup with Kyverno for license compliance verification
  • Your container images automatically include SBOM information in their attestations
  • Only images with acceptable licenses can be deployed in the specified namespace
  • Images with non-compliant licenses are automatically blocked by Kyverno policies
  • You have implemented a basic supply chain security control by verifying the license information of components in your container images

This guide provides a foundation for implementing license compliance verification in your CI/CD pipelines. In a production environment, you should:

  1. Configure proper namespace isolation and access controls
  2. Implement secure key management for signing keys
  3. Set up monitoring and alerting for policy violations
  4. Regularly update security policies based on your license requirements

#References

  • Base Image and SBOM Verification