红帽全球峰会第 4 章 程序错误修复
在此 Red Hat Trusted Artifact Signer (RHTAS)发行版本中，我们修复了以下 bug。除了这些修复外，我们还列出了我们修复的早期版本中已知的问题描述。
- Operator 在恢复到不同的 OpenShift 集群后不会更新组件状态
- 当将 RHTAS 签名器数据从备份恢复到新的 OpenShift 集群时，组件状态链接不会如预期更新。在这个版本中，我们解决了与组件状态相关的问题。
- 当将 Trusted Artifact Signer 恢复到不同的 OpenShift 集群时，
ownerReferences会丢失 -
将 RHTAS 数据恢复到新的 Red Hat OpenShift 集群时，组件的
ownerReferences将会丢失。这是因为 Securesign UUID 在在新集群中恢复时发生了变化，并且每个组件的ownerReferences会被删除，因为它们不再有效。在这个版本中，我们通过组件的ownerReferences解决了这个问题。
- Trusted Artifact Signer Operator 不会应用配置更改
- 在这个版本中，以前确保部署处于预期状态的 Operator 逻辑会存在差距，从而导致部署修改问题。因此，如果配置部分被主动删除，则部署可能与预期状态不匹配。在这个版本中，负责维护部署的预期状态的功能经过全面重新设计和替换，从而消除了这一差距。因此，新功能可以正确地处理任何资源更新，确保部署始终处于所需的状态。
- 为 TUF 存储库指定 PVC 名称会失败
- 在本发行版本中，我们更新了 RHTAS Operator，以正确地解释更新框架(TUF)资源的持久性卷声明(PVC)的名称置备。在此次更新之前，因为这个错误解译，不会初始化 TUF 存储库。在这个版本中，Operator 在创建 TUF 存储库时将使用提供的名称，确保正确初始化具有指定名称的 TUF 存储库。
- 即使
externalAccess.enabled设为false，也会创建 ingress 对象 -
在这个版本中，Operator 创建入口对象的逻辑现在会主动评估 Securesign 自定义资源中的
externalAccess设置。在此次更新之前，这个评估不正确，导致为 Fulcio、Rekor Search UI 和 Timestamp Authority 创建 ingress 对象，即使externalAccess.enabled被设置为false。在这个版本中，Operator 在创建 ingress 对象前确保externalAccess.enabled为true，防止在为组件有意禁用外部访问时创建 ingress 对象。这个更改可以正确地反映 Securesign 自定义资源中指定的配置。
- 在信任 root 中显示正确的摘要算法
在此次更新之前，更新框架(TUF)不会完全验证信任根。这会导致密钥的错误签名算法显示 SHA384 而不是 SHA256，从而导致签名目标信任 root 中的密钥详情不正确。这个问题已通过向 TUF 添加额外的密钥验证来解决。因此，签名的目标信任 root 现在会在新部署上显示正确的密钥详情。现有部署需要轮转 Rekor 键才能正常工作。
有关如何为在 Red Hat OpenShift 或 Red Hat Enterprise Linux 上运行的 RHTAS 轮转 Rekor 的 signer 密钥的详情，请查看 RHTAS 管理指南。
- 将 Rekor signer 密钥创建从 SHA384 降级为 SHA256
- 在此次更新之前，RHTAS Operator 和 Ansible 集合创建了与 Rekor 的 256 位要求不兼容的 signer 密钥，从而导致潜在的验证问题。这是因为生成 384 位 SHA384 密钥而不是预期的 256 位 SHA256 密钥。在这个发行版本中，我们调整了签名者密钥使其与 Rekor 的规格一致，从而提高了最终用户的兼容性和稳定性。
- 因为非受管数据库连接，在高负载下不稳定的服务
- 在这个版本中，客户端组件的默认数据库连接池，如 Trillian 日志服务器以前没有限制，从而导致在负载过重时对数据库有过量 TCP 连接。这会导致客户端 pod 上的临时端口耗尽，从而导致组件崩溃 "cannot assign requested address" 错误和后续失败，包括来自 Fulcio 的 "500 Internal Server Error" 响应。在这个版本中，为 Rekor 和 Trillian 数据库客户端设置了限制，控制打开和闲置连接的最大数量，以及连接生命周期。这种改进可确保系统在高负载条件下保持稳定，防止端口耗尽和消除 "cannot assign requested address" 错误和后续失败。
- 系统重启后，
cli-server和rekor-search组件没有响应 -
我们修复了 RHTAS 组件的镜像拉取策略，即
cli-server和rekor-search，后者之前以Alwayspull 策略运行，与其他 RHTAS 组件不同。因此，在重启 Red Hat Enterprise Linux 后，registry.redhat.io的本地身份验证将会丢失，从而导致这两个服务重复尝试拉取本地可用的镜像。因此，由于镜像拉取错误，这两个服务都无法启动，从而导致cli-server无响应并防止依赖功能在重启后正常工作。在这个版本中，这些服务的镜像拉取策略已切换到IfNotPresent，允许它们使用已缓存的本地镜像。因此，两个组件现在重启后可以成功启动，而无需重新身份验证到外部 registry。
- 因为文件权限不正确，cosign 初始化失败
-
在这个版本中，我们修复了 Update Framework (TUF)元数据卷中
root.json文件的权限，以匹配644的 TUF 默认值。此调整允许 Web 服务器读取文件，从而解决之前导致对root.json的请求返回 403 Forbidden 消息的问题，从而阻止 TUF 客户端和工具引导。负责编写和同步root.json文件的进程也已更新，以确保正确权限。因此，TUF 客户端现在可以初始化信任链且没有错误。
- 将
rekor-server部署到 default 命名空间 -
升级到 RHTAS 1.3，
rekor-server会在没有非 root UID 和 GID 的情况下使用容器镜像进行部署，从而导致 Pod Security Admission 阻止 pod 创建，并防止服务可用。在这个版本中，我们更新了 Dockerfile 以明确设置非 root UID 和 GID。因此，rekor-serverpod 现在可以在 RHTAS 1.3 的默认命名空间中创建。
'%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}