How to Integrate with a Self-Hosted Sigstore Instance for Image Signature Validation

Overview

A self-hosted Sigstore deployment allows your organization to control all signing and verification infrastructure, including Fulcio, Rekor, and TUF services.
When integrated with Sysdig Secure, this configuration enables verification of container images signed within your internal CI/CD pipelines using your own OIDC provider or managed signing keys.

Sysdig leverages Cosign to verify signatures at admission.
All verification logic is defined within the backend Image Signature Validation Policy—no Fulcio, Rekor, or OIDC configuration is required in the Cluster Shield chart.

Purpose

A self-hosted Sigstore instance provides full control over your signing and trust domain.
Integrating it with Sysdig ensures that only images signed through your internal trust root are admitted to your clusters.

During deployment, Sysdig verifies each image against your configured trust root and OIDC identity to ensure that:

  • Only verified images signed through your internal Sigstore instance are admitted to the cluster.
  • Supply chain integrity is maintained from build to production.
  • Tampering and substitution attacks are blocked before execution.
  • Compliance frameworks (for example, SLSA or NIST 800-204D) are supported through transparent verification and logging.

Benefits

CapabilityDescription
Private signing authorityUses your internal Fulcio CA and Rekor log instead of the public Sigstore services.
Flexible identity verificationValidates signatures using your enterprise OIDC provider or managed signing keys.
Policy-driven enforcementDefines trust roots and identities in Sysdig Supply Chain Policies, not runtime configuration.
Admission-time protectionEnforces policy decisions during Kubernetes admission control through Cluster Shield.

Summary

Integrating a self-hosted Sigstore instance with Sysdig Cluster Shield allows your organization to enforce container signature verification under your own trust and identity systems. Sysdig performs verification through Cosign using policy-defined parameters for OIDC or Public Key validation. Both mechanisms are supported but mutually exclusive.

Configuration

Cluster Shield

You don’t need to configure Sigstore endpoints or OIDC values directly in Cluster Shield.
Instead, enable signature verification globally. Sysdig performs Cosign verification based on the backend policy.

features:
  supply_chain:
    enabled: true
    image_signature:
      cosign:
        enabled: true
        mirror: https://tuf.example-trusted-artifacts.sysdig.com
        ## Optional: set only if root.json differs from the default Sigstore location.
        root: https://tuf.example-trusted-artifacts.sysdig.com/example/root.json
        root_checksum: sha256:8d31cb9e6b5f89c224e621e1eac5e4d3bcd20a02e31d69394f0f8b62f88e743c

Cluster Shield handles enforcement at runtime. The verification method (OIDC or key-based) and trust root are configured in the policy.

Policy Configuration (Backend)

Configure verification parameters within the Image Signature Validation Policy. You can use one of two mutually exclusive mechanisms:

1. Public Key Verification

Use public key verification if your build pipeline signs images with a managed or long-lived key pair. Provide the PEM-encoded public key in the policy:

-----BEGIN PUBLIC KEY-----
MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAXWRPQyGlEY+SXz8Uslhe+MLjTgWd8lf/
nA0hgCm9JFKC1tq1S73cQ9naClNXsMqY7pwPt1bSY8jYRqHHbdoUvwIDAQAB
-----END PUBLIC KEY-----

Sysdig verifies signatures against this key during admission control.

2. OIDC Provider Verification

Use when your self-hosted Sigstore issues certificates through an enterprise OIDC provider such as Keycloak, Okta, or Azure AD.

Configure the following fields in the policy:

FieldExample ValueDescription
OIDC Issuerhttps://keycloak.ci.internal/realms/buildThe OIDC issuer URL used by your Fulcio CA.
Certificate Identity^system:serviceaccount:ci-pipeline:signer$Regex for the signer identity within your organization.
Certificate Chain (optional)PEM-encoded chain to override the default TUF root.

Example chain:

-----BEGIN CERTIFICATE-----
MIIGczCCBJegAwIBAgIQDk... (Server Certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIF7jCCA9mgAwIBAgIQ... (Intermediate Certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIF7jCCA9mgAwIBAgIQ... (Root Certificate)
-----END CERTIFICATE-----

Note: The Certificate Chain override is optional and used only if you want to pin Sysdig’s verification to a specific Fulcio/TUF root different from the Cluster Shield-configured root.

Example Use Cases

  • Enforce that all internal workloads are signed by your enterprise Fulcio OIDC CA.
  • Pin signature verification to your internal TUF root for air-gapped clusters.
  • Prevent images signed through public Sigstore infrastructure from running in restricted clusters.

See Also