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
- CLI Repository
- Config Repository
- CRDs Repository
- Hacks Repository
- Infra-Deployments-CI Repository
- Policy Repository
- Review-Rot Repository
- Tekton-Catalog Repository
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.shSample 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.shSample 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 snapshotTARGET_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 successfullygenerate-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 URLFULCIO_URL- Fulcio certificate authority URLISSUER_URL- OIDC issuer URLTUF_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 JSONBUNDLE_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 --rawSample 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 policiesshow-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-gathertool - Validates
go-gatherfunctionality - 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_TOKENSample 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 addressEXTERNAL_REGISTRY- External registry port mappingIMAGE_NAME- Demo application image nameUSER_NAMESPACE- Namespace for cross-namespace demonstration
Example Usage:
# Run the complete VSA generation demo
./hack/demos/demo-vsa-generation.shSample 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 attachmentsREPOSITORY- 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
| Category | Purpose | Key Scripts |
|---|---|---|
| ๐๏ธ Development Setup | Prepare development environments | |
| ๐งช Testing & Demo | Run tests and demonstrations | |
| ๐ Build & Release | Build and release components | |
| ๐ญ Infrastructure | Manage deployments and infrastructure | |
| ๐งน Maintenance | Routine maintenance and updates | |
| ๐ Monitoring | Check status and versions |
โจ Best Practices
๐ Before Running Scripts
| โ Do | โ Don’t |
|---|---|
|
|
|
|
๐ง 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-runfor 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 psRegistry 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.shMissing 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.shImage 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:
| Step | Action | Example |
|---|---|---|
| 1๏ธโฃ | Include appropriate license headers | Copy from existing scripts |
| 2๏ธโฃ | Add usage documentation in comments | # Usage: ./script.sh [options] |
| 3๏ธโฃ | Follow existing naming conventions | Use kebab-case: my-new-script.sh |
| 4๏ธโฃ | Test thoroughly before committing | Test in clean environment |
| 5๏ธโฃ | Update this documentation | Add 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 arg1ec-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, ortext(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 yaml3. Detailed inspection with verbose output:
# Show detailed information including source resolution
ec inspect policy-data --policy policy.yaml --verbose --sources --rule-data4. 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 --sourcesSample 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 presentSample 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 yaml3. 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'
doneTroubleshooting:
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"