Tips and Tricks

This document serves as a comprehensive guide to all the utility scripts available in the “hack” and “hacks” directories across the Conforma organization repositories. These scripts provide essential tooling for development, testing, deployment, and maintenance of the Conforma ecosystem.

Additionally, this document contains tips, tricks, and other bits of ephemera related to the Conforma ecosystem.

Introduction

The Conforma organization maintains several repositories that contain utility scripts in their “hack” or “hacks” directories. These scripts are essential tools for developers, maintainers, and operators working with the Conforma ecosystem. This guide provides a comprehensive overview of all available scripts, their purposes, and usage instructions.

Table of Contents

Repositories

Reference Sections

Tricks and Tips

CLI Repository

Repository: conforma/cli
Purpose: Command line client for verifying artifacts and evaluating policies

The CLI repository contains the ec tool, which is used to evaluate Conforma policies for Software Supply Chain security. It validates container image signatures, provenance, and evaluates policies over container image provenance.

Scripts in /hack directory:

Development & Testing Scripts

demo.sh ๐Ÿ”—

Purpose:

  • Runs a demonstration of the EC tool against pre-built images.
  • Creates a demo namespace and EnterpriseContractPolicy, then evaluates policies against sample images.
  • Perfect for testing and demonstrations.

Environment Variables:

  • EC_DEBUG=1 - Enables debug output for detailed logging

Example Usage:

# Basic demo run
./hack/demo.sh

# With debug output
EC_DEBUG=1 ./hack/demo.sh

Sample Output:

Using ec version v0.7.0+redhat
โœจ Creating demo namespace and policy...
๐Ÿฉบ Evaluating policy for quay.io/example/image:latest
๐Ÿ’ฒ ec validate image --image quay.io/example/image:latest --policy demo/ec-demo
{
  "success": true,
  "violations": [],
  "warnings": []
}

setup-dev-environment.sh๐Ÿ”—

Purpose:

  • Sets up a complete development environment
  • Creates a Kind cluster with Tekton Pipeline
  • Installs Enterprise Contract Policy CRDs
  • Loads Tekton Task bundles
  • Essential for local development setup

Environment Variables:

  • KIND_CLUSTER_NAME - Name of the Kind cluster (default: “ec”)
  • REGISTRY_PORT - Port for the local registry (default: 5000)

Example Usage:

# Default setup
./hack/setup-dev-environment.sh

# Custom cluster name and registry port
KIND_CLUSTER_NAME=my-ec-cluster REGISTRY_PORT=5001 ./hack/setup-dev-environment.sh

Sample Output:

โœจ Installing development resources
โœจ Waiting for the image registry to become available
deployment.apps/registry condition met
โœจ Generating ingress controller certificate
โœจ Waiting for Tekton Pipelines to become available
deployment.apps/tekton-pipelines-controller condition met
โœจ Done
The work namespace is set as current and prepared to run the verify-enterprise-contract Tekton Task.

setup-test-environment.sh๐Ÿ”—

Purpose:

  • Sets up testing environment
  • Similar to dev environment but optimized for testing
  • Configures test-specific resources

rebuild.sh๐Ÿ”—

Purpose:

  • Rebuilds test images
  • Regenerates images used in demos and tests
  • Updates attestation data when needed

Build & Release Scripts

cut-release.sh๐Ÿ”—

Purpose:

  • Automates the release process
  • Creates release tags and builds
  • Handles version management
  • Publishes release artifacts

derive-version.sh๐Ÿ”—

Purpose:

  • Derives version information from git
  • Calculates semantic version from git history
  • Used by build processes

Arguments:

  • [BUILD_SUFFIX] - Optional build suffix (e.g., “redhat”) appended as build metadata

add-auto-tag.sh๐Ÿ”—

Purpose:

  • Adds automatic tagging to repositories
  • Automates version tagging workflow
  • Integrates with CI/CD pipelines

Deployment & Infrastructure Scripts

update-infra-deployments.sh๐Ÿ”—

Purpose:

  • Updates infrastructure deployment configurations
  • Synchronizes with infra-deployments repository
  • Updates deployment manifests

update-build-definitions.sh๐Ÿ”—

Purpose:

  • Updates build definition references
  • Keeps build definitions in sync
  • Updates Tekton pipeline references

bump-tekton-bundles.sh๐Ÿ”—

Purpose:

  • Updates Tekton bundle references
  • Bumps bundle versions in configurations
  • Ensures latest task definitions are used

Image & Registry Scripts

copy-snapshot-image.sh๐Ÿ”—

Purpose:

  • Copies snapshot images between registries
  • Facilitates image promotion workflows
  • Copies container images from snapshots to target repositories with proper tagging

Arguments:

  • SNAPSHOT_SPEC - JSON specification of the snapshot
  • TARGET_REPO - Target repository for image copying

Example Usage:

# Copy image from snapshot to target repository
./copy-snapshot-image.sh '{
  "components": [{
    "containerImage": "quay.io/source/app@sha256:abc123...",
    "source": {
      "git": {
        "revision": "abc123def456",
        "url": "https://github.com/myorg/myapp"
      }
    }
  }]
}' "quay.io/target/promoted-app"

Sample Output:

Target repo: quay.io/target/promoted-app
Verifying snapshot contains a single component
Pushing image with tag latest
Copying quay.io/source/app@sha256:abc123... to quay.io/target/promoted-app:latest
โœ… Image copied successfully
Pushing image with tag kf-abc123def456
Copying quay.io/source/app@sha256:abc123... to quay.io/target/promoted-app:kf-abc123def456
โœ… Image copied successfully

generate-test-signed-images.sh๐Ÿ”—

Purpose:

  • Creates test images with signatures
  • Generates signed images for testing keyless acceptance tests
  • Creates attestation data
  • Sets up complete Sigstore infrastructure

Prerequisites: Requires entries in /etc/hosts for local services

Usage: ./generate-test-signed-images.sh (no arguments)

Environment Variables:

  • REKOR_URL - Rekor transparency log URL
  • FULCIO_URL - Fulcio certificate authority URL
  • ISSUER_URL - OIDC issuer URL
  • TUF_MIRROR - TUF metadata mirror URL

ubi-base-image-bump.sh๐Ÿ”—

Purpose:

  • Updates UBI base image references
  • Keeps base images current
  • Handles security updates

Specialized Tools

expand-snapshot.sh๐Ÿ”—

Purpose:

  • Expands application snapshot data

  • Processes snapshot resources

  • Extracts component information

  • Arguments:

    • SNAPSHOT_NAME - Name of the snapshot (with optional namespace prefix)
    • CLI_SNAPSHOT_PATH - Output path for CLI snapshot JSON
    • BUNDLE_SNAPSHOT_PATH - Output path for bundle snapshot JSON
  • Usage: ./expand-snapshot.sh "namespace/snapshot-name" cli.json bundle.json

reduce-snapshot.sh๐Ÿ”—

Purpose:

  • Reduces snapshot data for testing
  • Creates minimal test snapshots
  • Optimizes for specific test scenarios

view-clair-reports.sh๐Ÿ”—

Purpose:

  • Views Clair vulnerability scan reports
  • Displays security scan results
  • Helps with vulnerability assessment

Config Repository

Repository: conforma/config
Purpose: Enterprise Contract configuration files for various environments

The Config repository contains policy.yaml files for different environments including Konflux CI, Red Hat internal builds, and GitHub Actions workflows.

Scripts in /hack directory:

update-infra-deployments.sh๐Ÿ”—

Purpose:

  • Updates infrastructure deployment configurations
  • Synchronizes configuration changes with deployment repositories
  • Ensures consistency across environments

verify-policy-sources.sh๐Ÿ”—

Purpose:

  • Verifies policy source integrity
  • Validates policy bundle references
  • Checks for broken or invalid policy sources
  • Ensures all referenced policies are accessible

CRDs Repository

Repository: conforma/crds
Purpose: Custom Resource Definitions for Enterprise Contract Policies

The CRDs repository provides Kubernetes CRD definitions for EnterpriseContractPolicy resources, enabling policy management in Kubernetes environments.

Scripts in /hack directory:

next-version.sh๐Ÿ”—

Purpose:

  • Calculates next version number
  • Determines appropriate version bumps
  • Integrates with release workflows

update-infra-deployments.sh๐Ÿ”—

Purpose:

  • Updates CRD deployments
  • Synchronizes CRD changes with infrastructure
  • Ensures latest CRD versions are deployed

Hacks Repository

Repository: conforma/hacks
Purpose: Collection of ad hoc scripts and tooling used by the Conforma team

This repository serves as a central location for utility scripts that don’t belong to a specific component but are useful across the organization.

Scripts in root directory:

chains-logs.sh๐Ÿ”—

Purpose:

  • Retrieves Tekton Chains logs
  • Collects logs from Tekton Chains components
  • Useful for debugging supply chain attestation issues

copy-public-sig-key.sh๐Ÿ”—

Purpose:

  • Copies public signing keys
  • Distributes public keys for signature verification
  • Manages key rotation workflows

rpm-version-checker.sh๐Ÿ”—

Purpose:

  • Checks RPM package versions
  • Validates RPM package versions in builds
  • Ensures version consistency

show-deployed-ec-policies.sh๐Ÿ”—

Purpose:

  • Shows currently deployed EC policies
  • Queries multiple repositories to determine active policy versions across the Konflux ecosystem
  • Provides essential visibility into policy deployment status

Arguments:

  • [--raw] - Shows raw grep results without processing
  • [--short] - Shows simplified output with just version information
  • [default] - Shows commit messages for deployed policy versions

Example Usage:

# Default: Show commit messages for deployed policies
./show-deployed-ec-policies.sh

# Short format: Just show version information
./show-deployed-ec-policies.sh --short

# Raw format: Show unprocessed grep results
./show-deployed-ec-policies.sh --raw

Sample Output (Default):

git@github.com:redhat-appstudio/infra-deployments.git:
--------------------------------------------------------
    commit 9e347db8c2f1a3b5d7e9f0a1c3e5g7h9i1k3m5o7
    Author: Policy Bot <policy@conforma.dev>
    Date:   Mon Dec 8 15:30:00 2024 -0500
    
        Update policy bundle to include new SLSA requirements
        
        - Add stricter provenance validation
        - Update trusted task definitions
        - Enhance supply chain security checks

git@gitlab.cee.redhat.com:releng/konflux-release-data.git:
----------------------------------------------------------
    commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
    Author: Release Engineering <releng@redhat.com>
    Date:   Mon Dec 8 14:15:00 2024 -0500
    
        Sync with latest enterprise contract policies

show-latest-build-versions.sh๐Ÿ”—

Purpose:

  • Displays latest build versions
  • Shows current versions of key components
  • Helps track component updates

test_go_gather.sh๐Ÿ”—

Purpose:

  • Tests the go-gather tool
  • Validates go-gather functionality
  • Runs integration tests

trust-local-cert.sh๐Ÿ”—

Purpose:

  • Configures trust for local certificates
  • Sets up certificate trust for development
  • Enables local HTTPS testing

update-tekton-task-bundles.sh๐Ÿ”—

Purpose:

  • Updates Tekton task bundle references
  • Synchronizes task bundle versions
  • Ensures latest task definitions are used

Subdirectories:

provenance/ - Contains provenance-related utilities

record.sh๐Ÿ”—

Purpose:

  • Records provenance data for testing
  • Provides sample pipeline and task definitions
  • Provides attestation examples for different SLSA versions

prune_quay_tags/ - Quay.io tag management

prune_quay_tags.sh๐Ÿ”—

Purpose:

  • Advanced container tag cleanup tool
  • Removes old container image tags based on age criteria
  • Essential for managing registry storage and cleaning up old builds
  • Provides sophisticated filtering options

Required Flags:

  • --repo <repository> - Quay.io repository name (e.g., “myorg/myrepo”)
  • --filter <regex> - Regular expression to filter tag names
  • --days <N> OR --before <YYYY-MM-DD> - Age criteria for deletion

Optional Flags:

  • --token <token> - Quay.io API token for authentication
  • --dry-run - Show what would be deleted without actually deleting

Example Usage:

# Dry run: Show PR tags older than 30 days
./prune_quay_tags.sh --repo myorg/myapp --filter "^pr-" --days 30 --dry-run

# Delete development tags before specific date
./prune_quay_tags.sh --repo myorg/myapp --filter ".*-dev$" --before 2024-01-01

# Clean up nightly builds older than 7 days
./prune_quay_tags.sh --repo myorg/myapp --filter "nightly-.*" --days 7 --token $QUAY_TOKEN

Sample Output:

๐Ÿ” Repo:    myorg/myapp
๐Ÿ”Ž Filter:  ^pr-
๐Ÿ“… Cutoff:  Before 2024-11-08 10:30:00 EST
๐Ÿงช Dryโ€‘run: ON

pr-123-abc123def                                                         2024-10-15 14:22:00 EST ๐Ÿ’ก would be deleted
pr-456-def456ghi                                                         2024-10-20 09:15:00 EST ๐Ÿ’ก would be deleted
pr-789-ghi789jkl                                                         2024-11-01 16:45:00 EST ๐Ÿ’ก would be deleted

๐Ÿงช Dry-run: would delete 3 tags matching "^pr-"

Infra-Deployments-CI Repository

Repository: conforma/infra-deployments-ci
Purpose: Keep infra-deployments updated with latest Enterprise Contract components

This repository automates the process of keeping infrastructure deployments synchronized with the latest Enterprise Contract components.

Scripts in /hack directory:

create-pr.sh๐Ÿ”—

Purpose:

  • Creates pull requests for infrastructure updates
  • Automates PR creation for component updates
  • Handles version bumps and dependency updates
  • Integrates with CI/CD workflows

Repository: conforma/knative-service
Purpose: Event-driven service for automatic enterprise contract verification

The Knative Service provides a Kubernetes-native, event-driven service that automatically triggers enterprise contract verification for application snapshots.

Scripts in /hack directory:

Testing & Demo Scripts

check-apiserversource.sh[๐Ÿ”—]

Purpose:

  • Verifies ApiServerSource configuration
  • Validates Knative eventing setup
  • Ensures proper event routing

test_ecp_lookup.sh[๐Ÿ”—]

Purpose:

  • Tests EnterpriseContractPolicy lookup
  • Validates policy resolution
  • Tests namespace-specific configurations

wait-for-ready-pod.sh[๐Ÿ”—]

Purpose:

  • Waits for pod readiness
  • Utility for deployment scripts
  • Ensures services are ready before testing

demo-vsa-generation.sh๐Ÿ”—

Purpose:

  • Demonstrates VSA (Verification Summary Attestation) generation

Complete End-to-End VSA Workflow Demo

Shows the complete VSA workflow including cross-namespace snapshot watching, policy validation, and Rekor integration. This comprehensive demo validates the entire Enterprise Contract verification pipeline.

Configuration Variables (set in script):

  • LOCAL_REGISTRY - In-cluster registry address
  • EXTERNAL_REGISTRY - External registry port mapping
  • IMAGE_NAME - Demo application image name
  • USER_NAMESPACE - Namespace for cross-namespace demonstration

Example Usage:

# Run the complete VSA generation demo
./hack/demos/demo-vsa-generation.sh

Sample Output:

๐ŸŽฏ VSA Generation Demo
======================
This demo shows the complete end-to-end workflow with:
  โœ… Cross-namespace Snapshot watching
  โœ… In-cluster registry (image accessibility)
  โœ… Image signatures (cosign)
  โœ… SLSA provenance attestations
  โœ… Policy validation
  โœ… VSA generation and upload

๐Ÿ“‹ Demo Configuration:
  Registry: registry.registry.svc.cluster.local:5000
  Image: registry.registry.svc.cluster.local:5000/vsa-demo-app:demo-1733680123
  Snapshot: vsa-demo-1733680123
  User Namespace: demo-user-namespace

๐Ÿ—๏ธ  Building and signing demo image...
โœ… Image built and pushed successfully
โœ… Image signed with cosign
โœ… SLSA provenance attestation created

๐Ÿ“ธ Creating Snapshot resource...
โœ… Snapshot created in demo-user-namespace

โฑ๏ธ  Waiting for VSA generation...
โœ… TaskRun completed successfully
โœ… VSA uploaded to Rekor transparency log
โœ… VSA signature verified

๐ŸŽ‰ Demo completed successfully!

Policy Repository

Repository: conforma/policy
Purpose: Rego policies for Enterprise Contract validation

The Policy repository contains the core policy rules written in Rego that define the Enterprise Contract compliance requirements.

Scripts in /hack directory:

add-auto-tag.sh[๐Ÿ”—]

Purpose:

  • Adds automatic tagging.
  • Automates version tagging for policy releases.
  • Integrates with release workflows

derive-version.sh[๐Ÿ”—]

Purpose:

  • Derives version from git history.
  • Calculates semantic versions.
  • Used in build and release processes

ec-opa.sh

Purpose:

  • Runs OPA with Enterprise Contract context.
  • Executes policy evaluation.
  • Provides EC-specific OPA configuration

refresh-examples.sh๐Ÿ”—

Purpose:

  • Updates example data and test cases.
  • Refreshes JSON sample files used by acceptance tests.
  • Updates trusted task definitions.
  • Maintains current image references and attestation data

Environment Variables:

  • IMAGE - Container image to use (default: quay.io/konflux-ci/ec-golden-image:latest)
  • ORIGINAL_IMAGE_REPO - Original repository for attachments
  • REPOSITORY - Git repository URL for the image source

Usage: ./refresh-examples.sh (no arguments, uses environment variables)

regal.sh[๐Ÿ”—]

Purpose:

  • Runs Regal linter for Rego policies
  • Validates policy syntax and style
  • Ensures policy quality standards

update-bundles.sh[๐Ÿ”—]

Purpose:

  • Updates policy bundle references
  • Synchronizes policy bundle versions
  • Ensures latest policies are packaged

update-infra-deployments.sh[๐Ÿ”—]

Purpose:

  • Updates infrastructure with new policies
  • Deploys policy changes to infrastructure
  • Maintains policy consistency across environments

validate-acceptable-bundles.sh[๐Ÿ”—]

Purpose:

  • Validates acceptable bundle configurations
  • Ensures bundle references are valid
  • Checks bundle accessibility and integrity

Review-Rot Repository

Repository: conforma/review-rot
Purpose: Generates review-rot page for the Conforma team

This repository generates automated reports about pull request review status across Conforma repositories.

Scripts in /hacks directory:

maintenance-helper.sh๐Ÿ”—

Purpose:

  • Assists with repository maintenance tasks
  • Automates routine maintenance operations
  • Helps with bulk repository updates

Tekton-Catalog Repository

Repository: conforma/tekton-catalog
Purpose: Tekton tasks provided by the Conforma team

This experimental repository contains Tekton task definitions that are consumed as Tekton Bundles produced by the CLI repository.

Scripts in /hack directory:

sync-ec-cli-tasks.sh๐Ÿ”—

Purpose:

  • Synchronizes tasks with Conforma CLI repository
  • Keeps task definitions in sync with CLI implementations
  • Ensures task compatibility with latest Conforma versions
  • Automates task bundle updates

๐Ÿš€ Common Usage Patterns

๐Ÿ› ๏ธ Development Environment Setup

Quick Start for New Developers:

# 1. Set up complete development environment
cd cli/
./hack/setup-dev-environment.sh

# 2. Run a demo to verify everything works
EC_DEBUG=1 ./hack/demo.sh

# 3. Check what policies are currently deployed
cd ../hacks/
./show-deployed-ec-policies.sh --short

๐Ÿ”„ Daily Development Workflow

Typical development cycle:

# Update your development environment
./hack/update-infra-deployments.sh

# Test your changes
./hack/demo.sh

# Check build versions
./show-latest-build-versions.sh

๐Ÿงน Registry Maintenance

Clean up old container images:

# Preview what would be deleted (dry run)
./prune_quay_tags.sh --repo myorg/myapp --filter "^pr-" --days 30 --dry-run

# Actually delete old PR images
./prune_quay_tags.sh --repo myorg/myapp --filter "^pr-" --days 30

# Clean up development tags older than 1 week
./prune_quay_tags.sh --repo myorg/myapp --filter ".*-dev$" --days 7

๐Ÿ“ฆ Image Promotion Pipeline

Promote images through environments:

# 1. Copy snapshot image to staging
./copy-snapshot-image.sh "$SNAPSHOT_JSON" "quay.io/myorg/app-staging"

# 2. Expand snapshot for bundle processing
./expand-snapshot.sh "namespace/snapshot-name" cli.json bundle.json

# 3. Validate with policies
ec validate image --file-path cli.json --policy staging/policy

๐Ÿ“‚ Script Categories

CategoryPurposeKey Scripts
๐Ÿ—๏ธ Development SetupPrepare development environments
๐Ÿงช Testing & DemoRun tests and demonstrations
๐Ÿš€ Build & ReleaseBuild and release components
๐Ÿญ InfrastructureManage deployments and infrastructure
๐Ÿงน MaintenanceRoutine maintenance and updates
๐Ÿ“Š MonitoringCheck status and versions

โœจ Best Practices

๐Ÿ“‹ Before Running Scripts

โœ… DoโŒ Don’t
  • Read script headers for usage instructions
  • Check environment variables and prerequisites
  • Verify you’re in the correct directory
  • Run scripts without understanding their purpose
  • Assume default values will work in your environment
  • Run scripts from arbitrary locations
  • Test in development environments first
  • Use –dry-run flags when available
  • Run destructive operations in production
  • Skip dry-run testing for cleanup scripts

๐Ÿ”ง Environment Setup Checklist

# Verify required tools are installed
command -v kubectl >/dev/null 2>&1 || echo "โŒ kubectl not found"
command -v kind >/dev/null 2>&1 || echo "โŒ kind not found" 
command -v cosign >/dev/null 2>&1 || echo "โŒ cosign not found"
command -v skopeo >/dev/null 2>&1 || echo "โŒ skopeo not found"

# Check authentication
kubectl auth can-i create pods --namespace=default
docker login quay.io

๐Ÿšจ Safety Guidelines

  • Always use --dry-run for destructive operations first
  • Backup important data before running maintenance scripts
  • Check script output for errors before proceeding
  • Use version control to track configuration changes
  • Test in isolated environments before production use

๐Ÿ”ง Troubleshooting Common Issues

๐Ÿ› Development Environment Problems

Kind cluster creation fails:

# Check if cluster already exists
kind get clusters

# Delete existing cluster if needed
kind delete cluster --name ec

# Verify Docker/Podman is running
docker ps

Registry authentication errors:

# Check authentication status
docker login quay.io

# For Podman users
podman login quay.io

# Verify credentials are stored
cat ~/.docker/config.json | jq '.auths'

๐Ÿšจ Script Execution Issues

Permission denied errors:

# Make scripts executable
chmod +x hack/*.sh

# Check script location
ls -la hack/demo.sh

Missing dependencies:

# Install common tools on Fedora/RHEL
sudo dnf install kubectl podman skopeo cosign

# Install on Ubuntu/Debian
sudo apt install kubectl podman skopeo

๐Ÿ“Š Policy and Image Issues

Policy validation failures:

# Check policy syntax
ec opa test ./policy

# Verify image signatures
cosign verify --key cosign.pub quay.io/example/image:tag

# Debug with verbose output
EC_DEBUG=1 ./hack/demo.sh

Image not found errors:

# Verify image exists
skopeo inspect docker://quay.io/example/image:tag

# Check registry connectivity
curl -I https://quay.io/v2/

๐Ÿค Contributing

Adding New Scripts

When contributing new scripts to any repository:

StepActionExample
1๏ธโƒฃInclude appropriate license headersCopy from existing scripts
2๏ธโƒฃAdd usage documentation in comments# Usage: ./script.sh [options]
3๏ธโƒฃFollow existing naming conventionsUse kebab-case: my-new-script.sh
4๏ธโƒฃTest thoroughly before committingTest in clean environment
5๏ธโƒฃUpdate this documentationAdd to appropriate repository section

๐Ÿ“ Documentation Standards

#!/usr/bin/env bash
# Copyright The Conforma Contributors
# SPDX-License-Identifier: Apache-2.0

# Brief description of what the script does
#
# Usage: ./script.sh [OPTIONS] ARGS
#   OPTIONS:
#     --flag VALUE    Description of flag
#     --dry-run       Show what would be done
#   ARGS:
#     arg1           Description of argument
#
# Examples:
#   ./script.sh --flag value arg1
#   ./script.sh --dry-run arg1

ec-inspect

Inspecting Policy Data

The ec inspect policy-data command is a powerful utility for examining and analyzing policy configurations and their associated data within the Enterprise Contract ecosystem. This command is essential for debugging policy issues, understanding policy structure, and auditing policy configurations.

Purpose:

  • Inspects and displays detailed information about policy data
  • Analyzes policy configuration structure and content
  • Validates policy data integrity and format
  • Provides debugging information for policy troubleshooting
  • Extracts rule data and policy sources for analysis

Usage:

$ ec inspect policy-data [OPTIONS]

Arguments:

  • --policy <POLICY> - Policy configuration file or Kubernetes resource reference
  • --output <FORMAT> - Output format: json, yaml, or text (default: text)
  • --verbose - Enable verbose output with additional details
  • --rule-data - Display rule data configurations
  • --sources - Show policy source information
  • --effective-time <TIME> - Inspect policy data as of specific time (RFC3339 format)

Example Usage:

1. Basic policy data inspection:

# Inspect policy from file
ec inspect policy-data --policy policy.yaml

# Inspect policy from Kubernetes resource
ec inspect policy-data --policy "namespace/policy-name"

2. Output in different formats:

# JSON output for programmatic processing
ec inspect policy-data --policy policy.yaml --output json

# YAML output for readability
ec inspect policy-data --policy policy.yaml --output yaml

3. Detailed inspection with verbose output:

# Show detailed information including source resolution
ec inspect policy-data --policy policy.yaml --verbose --sources --rule-data

4. Inspect specific policy components:

# Focus on rule data configuration
ec inspect policy-data --policy policy.yaml --rule-data --output json

# Show only policy sources
ec inspect policy-data --policy policy.yaml --sources

Sample Output (Text Format):

Policy Configuration Analysis
=============================

Policy Source: policy.yaml
Effective Time: 2024-12-08T15:30:00Z

Sources:
--------
- Name: policies
  Policy Sources:
    - git::github.com/conforma/policy.git//policy/lib?ref=main
    - git::github.com/conforma/policy.git//policy/release?ref=main
  Data Sources:
    - git::github.com/conforma/policy.git//data?ref=main

Configuration:
--------------
Include Rules:
  - slsa_source_version_controlled
  - github_certificate
  - step_image_registries

Rule Data:
----------
allowed_registry_prefixes:
  - quay.io/redhat-appstudio/
  - registry.redhat.io/
  - registry.access.redhat.com/

allowed_gh_workflow_repos:
  - myorg/myrepo

trusted_tasks:
  - name: buildah
    ref: quay.io/konflux-ci/tekton-catalog/task-buildah:0.1
  - name: git-clone
    ref: quay.io/konflux-ci/tekton-catalog/task-git-clone:0.1

Public Key: 
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZP/0htjhVt2y0ohjgtIIgICOtQtA
naYJRuLprwIv6FDhZ5yFjYUEtsmoNcW7rx2KM6FOXGsCX3BNc7qhHELT+g==
-----END PUBLIC KEY-----

Validation Status: โœ… Valid
Source Resolution: โœ… All sources accessible
Rule Data Validation: โœ… All required data present

Sample Output (JSON Format):

{
  "policy": {
    "sources": [
      {
        "name": "policies",
        "policy": [
          "git::github.com/conforma/policy.git//policy/lib?ref=main",
          "git::github.com/conforma/policy.git//policy/release?ref=main"
        ],
        "data": [
          "git::github.com/conforma/policy.git//data?ref=main"
        ],
        "ruleData": {
          "allowed_registry_prefixes": [
            "quay.io/redhat-appstudio/",
            "registry.redhat.io/"
          ],
          "allowed_gh_workflow_repos": [
            "myorg/myrepo"
          ],
          "trusted_tasks": [
            {
              "name": "buildah",
              "ref": "quay.io/konflux-ci/tekton-catalog/task-buildah:0.1"
            }
          ]
        }
      }
    ],
    "configuration": {
      "include": [
        "slsa_source_version_controlled",
        "github_certificate",
        "step_image_registries"
      ]
    },
    "publicKey": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZP/0htjhVt2y0ohjgtIIgICOtQtA\nnaYJRuLprwIv6FDhZ5yFjYUEtsmoNcW7rx2KM6FOXGsCX3BNc7qhHELT+g==\n-----END PUBLIC KEY-----"
  },
  "metadata": {
    "effectiveTime": "2024-12-08T15:30:00Z",
    "sourceResolution": "success",
    "validationStatus": "valid",
    "resolvedSources": 3,
    "includedRules": 3
  }
}

Common Use Cases:

1. Policy Debugging:

# Debug policy configuration issues
ec inspect policy-data --policy policy.yaml --verbose

# Check if all sources are accessible
ec inspect policy-data --policy policy.yaml --sources --output json | jq '.metadata.sourceResolution'

2. Policy Auditing:

# Generate policy audit report
ec inspect policy-data --policy policy.yaml --output json > policy-audit.json

# Extract rule data for compliance review
ec inspect policy-data --policy policy.yaml --rule-data --output yaml

3. Policy Validation:

# Validate policy structure before deployment
ec inspect policy-data --policy policy.yaml --verbose

# Check policy at specific point in time
ec inspect policy-data --policy policy.yaml --effective-time "2024-01-01T00:00:00Z"

4. Integration with Scripts:

# Extract trusted tasks for automation
TRUSTED_TASKS=$(ec inspect policy-data --policy policy.yaml --rule-data --output json | jq -r '.policy.sources[0].ruleData.trusted_tasks[].ref')

# Validate multiple policies
for policy in policies/*.yaml; do
  echo "Inspecting $policy..."
  ec inspect policy-data --policy "$policy" --output json | jq '.metadata.validationStatus'
done

Troubleshooting:

Policy source resolution failures:

# Check source accessibility with verbose output
ec inspect policy-data --policy policy.yaml --sources --verbose

# Test with specific git reference
ec inspect policy-data --policy policy.yaml --effective-time "2024-01-01T00:00:00Z"

Rule data validation errors:

# Inspect rule data structure
ec inspect policy-data --policy policy.yaml --rule-data --output yaml

# Validate against expected schema
ec inspect policy-data --policy policy.yaml --verbose | grep -A 10 "Rule Data Validation"