Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 4. Bug fixes
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.
- After a system reboot the
cli-serverandrekor-searchcomponents are unresponsive -
We fixed the image pull policy for the RHTAS components,
cli-serverandrekor-search, which previously operated with anAlwayspull policy, unlike other RHTAS components. Because of this, local authentication forregistry.redhat.iowould be lost after rebooting Red Hat Enterprise Linux, causing both services to repeatedly try pulling images that were already available locally. Consequently, both services failed to start due to image pull errors, makingcli-serverunresponsive and preventing dependent functionality from working after a reboot. With this release, the image pull policy for these services has been switched toIfNotPresent, allowing them to use the already-cached local images. As a result, both components now start successfully after a reboot, without requiring re-authentication to the external registry.
- Cosign initialization fails because of incorrect file permissions
-
With this release, we fixed the permissions of the
root.jsonfile within The Update Framework (TUF) metadata volume to match the TUF defaults of644. This adjustment allows the web server to read the file, resolving issues that previously caused requests toroot.jsonto return 403 Forbidden message, thereby blocking TUF clients and tools from bootstrapping. The process responsible for writing and syncing theroot.jsonfile has also been updated to ensure the correct permissions. As a result, TUF clients can now initialize the trust chain without errors.
- Deployed the
rekor-serverto the default namespace -
Upgrading to RHTAS 1.3, the
rekor-serverdeploys with a container image without a non-root UID and GID, causing the Pod Security Admission to block pod creation, and preventing the service from becoming available. With this release, we updated the Dockerfile to explicitly set a non-root UID and GID. As a result, therekor-serverpod can now be successfully created in the default namespace for RHTAS 1.3.
- 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. With this release we fixed this issue with the component status.
- The
ownerReferencesare lost when restoring Trusted Artifact Signer to a different OpenShift cluster -
When restoring the RHTAS data to a new Red Hat OpenShift cluster, the
ownerReferencesfor components are lost. This happens because the Securesign UUID changes when restoring on a new cluster, and theownerReferencesfor each component gets deleted since they are no longer valid. With this release we fixed this issue with theownerReferencesfor components.
- 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.enabledis set tofalse -
In this update, the Operator’s logic for creating ingress objects now actively evaluates the
externalAccesssetting 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 whenexternalAccess.enabledwas set tofalse. With this release, the Operator ensures thatexternalAccess.enabledistruebefore 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.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}