Release Notes

Ability to add OIDC providers for Ansible deployments of RHTAS

With this release, you can configure OpenID Connect (OIDC) providers under the tas_single_node_fulcio.fulcio_config section of the RHTAS Ansible Playbook. Update the playbook by adding your OIDC provider URL to the oidc_issuers variable, save your changes, and then re-run the playbook. You can have many OIDC providers defined in the oidc_issuers variable.

Monitoring for RHTAS containers

With this release, you can monitor and manage the RHTAS containers with the Cockpit web interface. This gives users a web-based user interface to simplify container management, and improves maintainability.

Expose passphrase variables for RHTAS components

When the Ansible collection creates a passphrase, they are easily guessable, and therefore a security risk. With this release, we expose the passphrase variables for each RHTAS component. This allows users to configure the passphrase as they see fit in the RHTAS Ansible Playbook.

Producing a warning or violation dynamically for policy checks

With this release of Enterprise Contract (EC), a single policy check can be either a warning or a violation based on logic defined in the policy check. You can select the warning or violation based on dynamic criteria, such as an effective date, or other runtime logic.

Improvements to the validation output

With this release, we added more details to the output of the ec validate image command for better auditing. The output shows the Git SHA or image digest when resolving a non-permanent reference, such as a tag or Git branch, if defined in the policy source for Enterprise Contract (EC). With this additional information you can see exactly which policies and policy data used during the validation.

Support for running Enterprise Contract commands without a timeout

With this release, you can specify the --timeout 0 on Enterprise Contract (EC) commands to override the default timeout of 5 minutes. This is helpful in Continuous Integration and Continuous Deployment (CI/CD) environments where they manage their own task timeouts.

Support for policy exceptions for specific components

In earlier versions of Enterprise Contract (EC), any policy exception was applied to all components being evaluated. With this release, you can specify which component a particular policy exception applies to. This gives you more fine-grained control when applying policy exceptions.

Fixed the formatting of solution links

We fixed an issue with the links that appear in the solutions and descriptions text outputted from the ec validate image command. The links to additional documentation now appear as a correctly formatted URL string.

Download size limitation for artifacts

We removed a download size limit on Open Container Initiative (OCI) fetches for artifacts larger than 10 MB. This limitation was causing artifacts to become truncated, leading to an error when accessing larger Software Bill of Materials (SBOM) documents.

Rekor unable to write attestations to storage

Rekor writes the attestation to the /tmp/ directory, and then tries to move the attestation to a persistent volume claim (PVC). The moving of the attestation file is really a "rename" operation within the code base. The "rename" operation only works for locations within the same mount point, but was failing when moving between mount points. With this release, we fixed this issue so Rekor can correctly write attestations to the PVC.

Fulcio service crash when configured with the Kubernetes OIDC issuer

A missing required certificate was causing the Fulcio service to crash with a fatal error when configured with the Kubernetes OpenID Connect (OIDC) issuer, for example, https://kubernetes.default.svc. This missing certificate was preventing the Fulcio service from running, and servicing signing requests. With this release, we fixed the issue by mounting the Kubernetes API server certificate to /var/run/fulcio/ca.crt, and the Fulcio service starts successfully when configuring the Kubernetes OIDC issuer.

Two Rekor log entries from one signature

When configuring Rekor and Certificate Transparency log with the same tree identifier in Trillian this causes two Rekor log entries for one signature. To fix this issue, configure Rekor and Certificate Transparency log with unique tree identifier.

Health probe for Trillian not working properly

A wrongly-formatted container command was not sending health probes to the trillian-mysql pod. This was generating error messages with the "unhealthy" or "improper" tags, even though the pod was healthy. With this release, we fixed the format of the container command, and the health probe reports the correct status.

Deploying RHTAS on Red Hat Enterprise Linux was creating anonymous volumes

The Rekor manifests did not have defined volumes. This created anonymous volumes with random names, making them hard to know who they belonged to. With this release, we fixed the Rekor manifests by adding proper volume mounting. We name the volumes as follows: redis-backfill-storage and rekor-redis-storage.

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.

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 workaound this issue, run the provided script after the Securesign resource is restored. This script recreates the ownerReferences with the new Securesign UUID.

Specifying a PVC name for the TUF repository fails the initialization process

When specifying a persistent volume claim (PVC) name in The Update Framework (TUF) resource causes the RHTAS operator to fail the initialization of the TUF repository. For example:

Rekor Search UI does not show records after upgrade

After upgrading the RHTAS operator to the latest version (1.0.1), the existing Rekor data is not found when searching by email address. The backfill-redis CronJob, 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.

The Trusted Artifact Signer operator does not apply configuration changes

We found a potential issue with the RHTAS operator logic that can cause an unexpected state when redeploying. This inconsistent state can happen if removing configurations from RHTAS resources and the operator tries to redeploy those resources. To workaround this potential issue, you can delete the specific resource, and then re-create that resource by using the previous instance’s configuration, such as keys, and persistent volumes. The RHTAS resources are: Securesign, Fulcio, The Update Framework (TUF), Rekor, Certificate Transparency (CT) log, or Trillian.

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.

Example

oc delete secret securesign-sample-trillian-db-tls

Example

oc edit --subresource=status Securesign securesign-sample
oc edit --subresource=status TimestampAuthority securesign-sample

Trusted Artifact Signer requires cosign 2.2 or later

Because of recent changes to how we generate The Update Framework (TUF) repository, and making use of different checksum algorithms, we require the use of cosign version 2.2 or later. With this release of RHTAS, you can download cosign version 2.4 for use with Trusted Artifact Signer.