Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Release Notes

Red Hat Trusted Artifact Signer 1.3

Release notes for Red Hat's Trusted Artifact Signer 1.3

Red Hat Trusted Documentation Team

Abstract

Welcome to Red Hat Trusted Artifact Signer's official release notes for version 1.3!
The release notes describes new features, enhancements, known issues, bug fixes, and deprecation implemented for the Red Hat Trusted Artifact Signer 1.3 software release.

Chapter 1. Introduction
Copy link

Red Hat’s Trusted Artifact Signer (RHTAS) service enhances software supply chain security by simplifying cryptographic signing and verifying of software artifacts, such as container images, binaries, and Git commits. Trusted Artifact Signer provides a production ready deployment of the SecureSign community project.

The Trusted Artifact Signer software Release Notes documents new features and enhancements, bug fixes, and known issues for the latest version, 1.3. We add the newest items to the top in each chapter, as we build upon the official release notes over the lifecycle of the major, and minor releases.

New for this release
  • Technology Preview : The ability to configure the RHTAS services for high-availability environments.
  • Technology Preview : Implementation of the Sigstore Policy Controller admission controller for Red Hat OpenShift Container Platform.
  • Technology Preview : Signing and verifying AI models.
  • Implementation of log monitoring for Rekor.
  • Improvements to make the RHTAS Operator error recovery more robust.
  • Enterprise Contract (EC) renamed to Conforma.
  • Various Conforma improvements and new features.

Chapter 2. Technology previews
Copy link

An overview of the Technology Preview features introduced or updated in this release of Red Hat Trusted Artifact Signer (RHTAS).

Important

Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about Red Hat Technology Preview features support scope, see https://access.redhat.com/support/offerings/techpreview/.

Trusted Artifact Signer Console
In this release, we added the RHTAS Console, a user-friendly graphical interface for viewing read-only information such as The Update Framework (TUF) root details and certificates. This improves the user’s quality of life when managing a RTHAS environment. Before this update, security details were distributed across multiple tools, causing a less user-friendly experience. With this release, users have a unified console, with more features being added in later RHTAS releases, such as: functionality for Rekor Search UI, Rekor keys, along with artifact retrieval and verification actions. For deployment instructions, please see the project’s repository on GitHub for more details.
Added the Sigstore Policy Controller admission controller
In this update, users can deploy the Sigstore Policy Controller admission controller alongside RHTAS deployments running on Red Hat OpenShift. This integration offers users a method to manage the container images that are permitted to operate on their OpenShift clusters, based on signatures or attestations generated by RHTAS. Users can install and manage the Sigstore Policy Controller admission controller by installing an Operator that reconciles the upstream Helm chart. This Operator ensures that cluster workloads are only allowed if they comply with the specified cluster image policies.
High availability support added for Trusted Artifact Signer on Red Hat OpenShift
With this update, users can now configure RHTAS for High Availability (HA) in single cluster deployments, enhancing service reliability and performance. The RHTAS deployment now keeps key components replicated to eliminate single points of failure, provides load balancing, fail over mechanisms, and health checks. This allows the system to manage workloads effectively, ensuring the uptime required for continuous CI/CD pipelines that rely on the Trusted Artifact Signer service, and maintaining operational continuity.
Support added for signing and verifying AI/ML models

With this release, we introduced a new Model Validation Operator, and a command-line procedure to do pod validation for artificial intelligence (AI) and machine learning (ML) models before running your workloads. The Model Validation Operator integrates a webhook to automatically inject an initialization container to do validation, ensuring that only verified models are used. This validation process works with the RHTAS service to validate the authenticity of the AI/ML models. You can also sign and verify AI/ML models by using the command-line interface, without needing to install a separate binary.

For more information, see the RHTAS Administration Guide.

New configuration options for scaling Trusted Artifact Signer’s services
With this update, we implemented enhanced pod scheduling and resource management for RHTAS. This enhancement provides granular control over scaling, scheduling, and resource allocation through a new PodRequirements specification. This addresses the need for fine-grained deployment options by offering control over Custom Resources (CR) such as: Fulcio, Certificate Transparency log (CTlog), Rekor, Trillian, Timestamp Authority (TSA), and The Update Framework (TUF) Trust Root. Users can now manage pod affinity rules, define a matching toleration for node taints, specify the number of replicas for high availability, and set compute resource requests and limits. These new configuration options are also exposed in the OpenShift console UI for easier management.
New configuration options for Rekor attestation storage
In this update, you can now configure external storage for Rekor attestations. This new feature enhances scalability and flexibility when managing Rekor attestations. This allows for the use of many Rekor replicas simultaneously. We expanded Rekor’s Custom Resource Definition (CRD) with a new attestations section. In this section you can specify a storage URL from storage providers such as: Amazon Web Services (AWS) S3, Google Cloud Storage (GCS), or a file-based persistent volume claim (PVC).
New configuration options for Rekor external search index
With this update, users can use their own Redis database to serve as the search index for Rekor. This integration enables connection with external, highly-available, and managed database or caching services. For production environments that demand greater scalability, reliability, and the ability to use existing infrastructure is essential. When an external search index is configured, the RHTAS Operator will not deploy the embedded Redis instance. Instead, the Rekor service actively uses the specified external connection configuration, which includes support for TLS-enabled connections. This gives users more flexibility, along with an enterprise-ready deployment of RHTAS, simplifying management and enhancing overall performance.

Chapter 3. New features and enhancements
Copy link

A list of all major enhancements, and new features introduced in this release of Red Hat Trusted Artifact Signer (RHTAS).

The features and enhancements added by this release are:

Rekor Transparency Log monitoring
In this release, we introduced the Rekor Transparency Log monitor for RHTAS. This feature monitors the Transparency Log periodically to verify the integrity of the log. It ensures the log is verifiable, consistent worldwide, append-only, and addressing the earlier lack of active verification over time. With this update, RHTAS runs the Rekor Transparency Log monitor alongside deployments, acting as an agent to continuously validate the transparency log. This provides stronger assurances to end users and increases trust in the security pipeline for the software supply chain.
Added a new configuration option for Fulcio
In this update, you can now configure the new option ciIssuerMetadata for Fulcio. This new option enables the creation of custom templates for X.509 v3 extensions in certificates generated by Fulcio for Continuous Integration (CI) providers. Before this update, hard-coded default values in X.509 v3 extensions could result in incorrect metadata, such as generic Git URIs appearing for private Git instances. With the addition of the ciIssuerMetadata setting, you can map OpenID Connect (OIDC) token claims to specific certificate extensions, ensuring the right environment-specific metadata. It also allows for the inclusion of additional user-defined information, such as user_login and user_email, in the certificate.
Enterprise Contract renamed to Conforma
With this update of RHTAS, the Red Hat product name, Enterprise Contract is deprecated, and has been renamed to Conforma. All Red Hat built container images, and documentation has been updated to use the new name. For more information about this name change, you can view the community post.
Conforma supports the OPA policy engine
With this release of RHTAS, we updated Conforma to support Open Policy Agent (OPA) version 1.0 and later. This includes the handling of breaking changes in Rego syntax. As a result, Conforma now supports OPA with proper handling of syntax transitions, ensuring continued policy evaluation capabilities while benefiting from security improvements and new features.
New configuration option for adding a Rekor public key for ec.sigstore.* functions
In this release, users can now customize the Rekor public keys by incorporating the rekor_public_key parameter in the ec.sigstore.verify_image and ec.sigstore.verify_attestation functions. This improvement facilitates more adaptable verification workflows with RHTAS deployments, as it resolves conflicts that arose when verifying various types of signatures within the same policy evaluation using the earlier environment variable approach. Policy authors can now verify signatures from different Rekor instances within the same policy execution, preserving backward compatibility.
Conforma hitting Quay rate limits
With this update, we implemented active rate limiting mitigation strategies, and a retry mechanism to prevent 429 Too Many Requests errors when accessing Quay.io registries. This enhancement addresses the disruptive rate limiting issues that can occur in build systems, improving the reliability when accessing container registries, and reducing incidents of rate limiting errors that can cause verification failures.

Chapter 4. Bug fixes
Copy link

In this release of Red Hat Trusted Artifact Signer (RHTAS), we fixed the following bugs. In addition to these fixes, we also list the descriptions of previously known issues found in earlier versions that we fixed.

The Trusted Artifact Signer Operator does not apply configuration changes
In this update, the Operator logic, which previously ensured deployment was in the expected state, had a gap, leading to issues with deployment modification. Consequently, if configuration parts were actively removed, the deployment might not match the expected state. With this release, the function responsible for maintaining the deployment’s expected state has been comprehensively redesigned and replaced, eliminating this gap. As a result, the new function correctly handles any resource updates, ensuring the deployment is always in the required state.
Specifying a PVC name for the TUF repository fails the initialization process
In this release, we updated the RHTAS Operator to correctly interpret the provision of a name for a Persistent Volume Claim (PVC) for The Update Framework (TUF) resource. Before this update, the TUF repository was not initialized due to this misinterpretation. With this update, during installation, the Operator will use the provided name when creating the TUF repository, ensuring that TUF repositories with a specified name are properly initialized.
Creation of ingress objects occurs even if externalAccess.enabled is set to false
In this update, the Operator’s logic for creating ingress objects now actively evaluates the externalAccess setting in the Securesign custom resource. Before this update, this evaluation was incorrect, leading to the creation of ingress objects for Fulcio, Rekor Search UI, and the Timestamp Authority even when externalAccess.enabled was set to false. With this release, the Operator ensures that externalAccess.enabled is true before an ingress object is created, preventing the creation of ingress objects when external access is intentionally disabled for a component. This change correctly reflects the configuration specified in the Securesign custom resource.
Displaying the correct digest algorithm within the trust root

Before this update, The Update Framework (TUF) did not validate trust roots thoroughly. This lead to displaying the wrong signature algorithm for keys as SHA384 instead of SHA256, resulting in incorrect key details in the signed target trust root. This issue has been addressed in this release by adding extra key validation to TUF. As a result, the signed target trust root will now show the correct key details on fresh deployments. Existing deployments will require rotation of the Rekor key for proper functioning.

For information about how to rotate Rekor’s signer key for RHTAS running on Red Hat OpenShift or on Red Hat Enterprise Linux, see the RHTAS Administration Guide.

Downgraded the creation of the Rekor signer key from SHA384 to SHA256
Before this update, the RHTAS Operator and Ansible collection created signer keys that were not compatible with Rekor’s 256-bit requirement, leading to potential validation issues. This was due to the generation of 384-bit SHA384 keys instead of the expected 256-bit SHA256 keys. In this release, we adjusted the signer keys to be consistent with Rekor’s specifications, resulting in improved compatibility and stability for end users.
Unstable service under high load because of unmanaged database connections
In this update, the default database connection pool for client components, such as, the Trillian log server previously had no limits, leading to excessive TCP connections to the database under heavy load. This resulted in ephemeral port exhaustion on client pods, causing component crashes with "cannot assign requested address" errors and subsequent failures, including "500 Internal Server Error" responses from Fulcio. With this release, limits have been set for the Rekor and Trillian database clients, controlling the maximum number of open and idle connections, and connection lifetimes. This improvement ensures the system remains stable under high load conditions, preventing port exhaustion and eliminating "cannot assign requested address" errors and subsequent failures.

Chapter 5. Known issues
Copy link

Resolved known issues for this release of Red Hat Trusted Artifact Signer (RHTAS):

A list of unresolved known issues found in this release, and earlier releases of RHTAS:

The Trillian CR status update fails
The Trillian custom resource (CR) fails to update the status.replicas field within the CR after a user specifies a custom number of replicas. This results in a mismatch between the number of replicas defined and the number reported in the CR status. Although the correct number of pods are deployed, the status field incorrectly displays the default value, which might cause confusion during monitoring. To work around this issue, manually update the status.replicas field in the CR to match the actual number of replicas. As a result of this workaround, the status field accurately reflects the number of replicas.
Cosign fails verification of signed timestamps after rotating the TSA certification chain

The current version of cosign expects only one single Timestamp Authority (TSA) certificate chain. When rotating the TSA certificate chain, you give the whole TSA certificate chain to The Update Framework (TUF) as an individual target. During the rotation process, setting the new TSA certificate chain as the new TUF target, and expiring the old TSA certificate chain gives the following error message:

main.go:74: error during command execution: unable to load TSA certificates: TSA certificate chain must contain exactly one leaf certificate

Currently, there is no workaround for this issue.

For information about rotating the TSA signer key and certificate chain see our procedure for Red Hat OpenShift Container Platform, or Red Hat Enterprise Linux.

The ownerReferences are lost when restoring Trusted Artifact Signer to a different OpenShift cluster
When restoring the RHTAS data to a new Red Hat OpenShift cluster, the ownerReferences for components are lost. This happens because the Securesign UUID changes when restoring on a new cluster, and the ownerReferences for each component gets deleted since they are no longer valid. To workaround this issue, run the provided script after the Securesign resource is restored. This script recreates the ownerReferences with the new Securesign UUID.
Rekor Search UI does not show records after upgrade

After upgrading the RHTAS Operator to the latest version, the existing Rekor data is not found when searching by email address. The backfill-redis Cron job, which ensures that Rekor Search UI can query the transparency log only runs once per day, at midnight. To workaround this issue, you can trigger the backfill-redis job manually, instead of waiting until midnight.

To trigger the backfill-redis job from the command-line interface, run the following command: 

$ oc create job --from=cronjob/backfill-redis backfill-redis -n trusted-artifact-signer
Copy to Clipboard Toggle word wrap

Doing this adds the missing data back to the Rekor Search UI.

Operator does not update the component status after doing a restore to a different OpenShift cluster

When restoring the RHTAS signer data from a backup to a new OpenShift cluster, the component status links do not update as expected. Currently, you have to manually delete the securesign-sample-trillian-db-tls resource, and manually update the component status links. The RHTAS operator will automatically recreate an updated securesign-sample-trillian-db-tls resource, after it has been removed.

After the backup procedure starts, and the secrets restored, delete the securesign-sample-trillian-db-tls resource: 

$ oc delete secret securesign-sample-trillian-db-tls
Copy to Clipboard Toggle word wrap

Once all the pods start, then update the status files for Securesign, and TimestampAuthority: 

$ oc edit --subresource=status Securesign securesign-sample
$ oc edit --subresource=status TimestampAuthority securesign-sample
Copy to Clipboard Toggle word wrap

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat