Chapter 4. Known issues
A list of unresolved known issues found in this release, and earlier releases of RHTAS:
- 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 theownerReferences
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 theownerReferences
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To workaround this issue, do not specify a PVC name in the TUF resource. This allows the RHTAS operator to automatically create the PVC, names it
tuf
, and properly initializes the TUF repository.
- 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 thebackfill-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
$ oc create job --from=cronjob/backfill-redis backfill-redis -n trusted-artifact-signer
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Doing this adds the missing data back to the Rekor Search UI.
- 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.
For example, to delete the
Securesign
resource:oc delete Securesign securesing-sample
$ oc delete Securesign securesing-sample
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example, to re-create the
Securesign
resource from a configuration file:oc create -f ./securesign-sample.yaml
$ oc create -f ./securesign-sample.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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 re-create an updatedsecuresign-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
$ oc delete secret securesign-sample-trillian-db-tls
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Once all the pods start, then update the status files for
Securesign
, andTimestampAuthority
:oc edit --subresource=status Securesign securesign-sample oc edit --subresource=status TimestampAuthority securesign-sample
$ oc edit --subresource=status Securesign securesign-sample $ oc edit --subresource=status TimestampAuthority securesign-sample
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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 downloadcosign
version 2.4 for use with Trusted Artifact Signer.