RHTAS Operator continuously monitors component Deployment health

Before this update, the Red Hat Trusted Artifact Signer (RHTAS) Operator stopped monitoring component Deployments (Rekor, Fulcio, CTLog, TUF, TSA, and Trillian) after their custom resource (CR) first reached a Ready condition. As a result, if a component Deployment was deleted or encountered a rollout failure, the Ready condition on the CR continued to report True indefinitely, preventing administrators and monitoring tools from detecting the outage.

With this update, the Operator continuously monitors each component’s Deployment for the lifetime of the CR. The Ready condition accurately reflects the live state of the Deployment at all times by correctly regressing to False if the Deployment becomes unhealthy and returning to True when it recovers.

Operator includes TSA certificate chain in TUF trusted root for KMS and TINK signers

Copy link

Before this update, The Update Framework (TUF) did not include the Time Stamping Authority (TSA) certificate chain when the TSA used a Key Management Service (KMS) or TINK signer configuration. As a result, client-side verification failed due to incomplete trust material in the trusted root.

With this update, the Operator retrieves trust material directly from component service APIs and stores it in component custom resource statuses. TUF uses this status information instead of labeled signer Secrets, ensuring the TSA certificate chain is included in the trusted root for file-based, KMS, and TINK signer configurations.

Operator automatically retries setup when API server registers custom resource definitions

Copy link

Before this update, during a fresh installation or Operator restart, the Kubernetes API server sometimes had not yet fully registered the Operator custom resource definitions. As a result, the Operator treated this temporary delay as a permanent failure and stopped creating required resources (ServiceAccounts, Roles, and RoleBindings), leaving the deployment in a broken state that required manual intervention.

With this update, the Operator recognizes unregistered custom resource definitions as a temporary condition and automatically retries setup until the API server is ready. Fresh installations and Operator restarts now complete successfully without manual intervention.

Operator-managed workloads explicitly drop Linux capabilities to support restricted Pod Security

Copy link

Before this update, Operator-managed workload manifests did not explicitly drop all Linux capabilities and relied on OpenShift Security Context Constraints (SCCs) to apply these settings. As a result, on clusters enforcing the restricted Kubernetes Pod Security standard, operand workloads were rejected and failed to deploy.

With this update, all Operator-managed containers and init containers explicitly drop all Linux capabilities. As a result, operand workloads deploy successfully in namespaces enforcing restricted Pod Security standards without relying on OpenShift SCC mutations.

Red Hat Trusted Artifact Signer upgrades via OLMv1 no longer fail due to ConsoleCLIDownload resource conflicts

Copy link

Before this update, when upgrading Red Hat Trusted Artifact Signer Operator from version 1.4.3 to 1.5.0 via Operator Lifecycle Manager v1 (OLMv1), Helm server-side dry-run operations failed. This failure occurred because ConsoleCLIDownload resources created at runtime by the 1.4.3 operator lacked the required Helm ownership metadata (app.kubernetes.io/managed-by, meta.helm.sh/release-name, and meta.helm.sh/release-namespace) for Helm to adopt existing cluster resources. As a result, the OLMv1 upgrade was blocked, leaving affected CLI download resources (cosign, rekor-cli, gitsign, ec, fetch-tsa-certs, createtree, updatetree, and tuftool) unupdated and the cluster on version 1.4.3.

With this update, static ConsoleCLIDownload bundle manifests are renamed with the rhtas- prefix (for example, rhtas-cosign), enabling Helm to create fresh resources without adoption conflicts. Additionally, a migration component automatically removes legacy resources that match the app.kubernetes.io/part-of: trusted-artifact-signer label upon operator startup. As a result, upgrades from version 1.4.3 to 1.5.0 via OLMv1 succeed without manual intervention, automatically replacing legacy ConsoleCLIDownload resources with newly named resources containing developer portal download links. Fresh installations are unaffected.

Certificate-based signing flow validates leaf certificate validity periods

Copy link

Before this update, the certificate-based signing flow verified only that a leaf certificate's public key matched the private key and did not validate its validity period. During verification, the X.509 store evaluation time was pinned to the certificate's own not_valid_before timestamp, causing expired or not-yet-valid certificates to always pass verification. As a result, expired or unvalidated signing certificates were silently accepted, allowing models signed with compromised or expired certificates to pass validation.

With this update, temporal validation for leaf certificates has been added at signing time. The signing process now rejects certificates with a not_valid_after timestamp in the past or a not_valid_before timestamp in the future. During verification, the X.509 store evaluates the certificate chain against the current system wall-clock time. Consequently, signing with an invalid certificate fails with an explicit error, and verification rejects bundles whose signing certificates fall outside their validity period in compliance with the Open Model Specification (OMS).

Validation for empty model directories during signing and verification

Copy link

Before this update, file enumeration did not verify whether a model directory contained at least one regular file after path exclusions were applied. Consequently, empty directories or directories where all files matched exclusion rules generated a manifest with an empty resources array. This allowed empty models to be signed and verified successfully, violating the Open Model Specification (OMS) requirement and undermining integrity guarantees. With this update, validation checks after file enumeration reject models that contain zero regular files. As a result, attempting to sign or verify an empty or fully excluded model directory fails with an explicit error: Model contains no regular files after exclusions are applied.

Policy controller supports Cosign v3 bundle-format signature verification

Copy link

Before this update, the policy controller looked up signatures exclusively by using tag-based Open Container Initiative (OCI) artifacts (.sig). Because Cosign version 3 stores signatures in the bundle format by using the OCI 1.1 Referrers API, the controller could not locate these signatures. As a result, the policy controller rejected container images signed with Cosign version 3 with a no signature found error, which blocked the deployment of valid images.

With this update, the policy controller supports signature verification for Cosign version 3 bundle formats. When you set signatureFormat: "bundle" in the ClusterImagePolicy authority configuration, the policy controller discovers and verifies signatures stored in the Cosign version 3 bundle format via the OCI 1.1 Referrers API, allowing signed images to pass validation.

Keyless verification flags now take precedence over policy public keys in ec validate image

Copy link

Before this update, running the ec validate image command with keyless identity flags, such as --certificate-identity and --certificate-oidc-issuer, but without the --public-key flag caused the command to silently ignore the keyless identity flags if the loaded Enterprise Contract policy defined a publicKey field. Consequently, keyless verification was not performed in pipelines that passed certificate identity parameters through environment variables while relying on a cluster policy with a default public key. With this update, explicit keyless identity flags take precedence over the publicKey setting in the policy when --public-key is omitted, ensuring that identity-based keyless verification runs as expected.

In-toto attestation type verification is now enforced for bundle payloads

Copy link

Before this update, the attestation bundle parser accepted any value for the in-toto _type field without validation, unlike non-bundle parsers that rejected unknown _type values. With this update, the bundle payload parser verifies the _type field during attestation parsing, ensuring that unknown or invalid in-toto attestation types are rejected in the bundle parsing path.

Enterprise Contract downloader now performs case-insensitive HTTP URL scheme validation

Copy link

Before this update, the Enterprise Contract downloader performed case-sensitive scheme validation on source URLs, which allowed mixed-case or uppercase HTTP schemes (such as Http:// or HTTP://) to bypass transport security checks. As a result, requests using mixed-case HTTP URLs were fetched over unencrypted HTTP connections. With this update, scheme validation converts URL schemes to lowercase before evaluation, ensuring that unencrypted HTTP URLs are detected and rejected consistently regardless of character casing.

Enterprise Contract now prevents backdated effective time from bypassing time-gated security rules

Copy link

Before this update, setting a past date with the --effective-time flag in ec validate input caused time-gated security rules to be suppressed. This occurred because the backdated time demoted rule failures to warnings and overridden the time reference across the rule evaluation stack, allowing validation to pass when running with the --strict flag. With this update, explicit --effective-time values more than two seconds in the past are rejected unless --allow-past-effective-time is supplied.”

Updated tufcli and gitsign CLI binaries resolve runtime failures in Red Hat Trusted Artifact Signer 1.5.0

Copy link