第4章 既知の問題


このリリースおよび RHTAS の以前のリリースで見つかった未解決の既知の問題のリスト:

Cosign は TSA 認証チェーンをローテーションした後、署名されたタイムスタンプの検証に失敗する

cosign の現在のバージョンでは前提として、Timestamp Authority (TSA) 証明書チェーンは 1 つだけ使用できます。TSA 証明書チェーンをローテーションする場合、TSA 証明書チェーン全体を個別のターゲットとして The Update Framework (TUF) に渡します。ローテーションプロセス中に、新しい TSA 証明書チェーンを新しい TUF ターゲットとして設定し、古い TSA 証明書チェーンを期限切れにすると、次のエラーメッセージが表示されます。

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

現在、この問題に対する回避策はありません。

TSA 署名者キーと証明書チェーンのローテーションは、Red Hat OpenShift Container Platform または Red Hat Enterprise Linux の手順を参照してください。

Trusted Artifact Signer を別の OpenShift クラスターに復元すると、ownerReferences が失われる

RHTAS データを新しい Red Hat OpenShift クラスターに復元すると、コンポーネントの ownerReferences が失われます。これは、新しいクラスターに復元するときに Securesign UUID が変更され、各コンポーネントの ownerReferences が有効でなくなるため削除されるため発生します。この問題を回避するには、Securesign リソースが復元された後に提供された スクリプト を実行します。このスクリプトは、新しい Securesign UUID を使用して ownerReferences を再作成します。

TUF リポジトリーの PVC 名を指定すると、初期化プロセスが失敗する

The Update Framework (TUF) リソースで永続ボリューム要求 (PVC) 名を指定すると、RHTAS Operator は TUF リポジトリーの初期化に失敗します。以下に例を示します。

spec:
...
  tuf:
    ...
      pvc:
        name: tuf-pvc-example-name
...
Copy to Clipboard Toggle word wrap

この問題を回避するには、TUF リソースに PVC 名を指定しないでください。これにより、RHTAS Operator は PVC を自動的に作成し、それに tuf という名前を付け、TUF リポジトリーを適切に初期化できるようになります。

アップグレード後は、Rekor Search UI にレコードが表示されない

RHTAS Operator を最新バージョンにアップグレードした後 (1.0.1)、メールアドレスで検索するときに既存の Rekor データが見つかりません。backfill-redis CronJob は、Rekor Search UI が透過性ログを 1 日 1 回 (午前 0 時に 1 回のみ) に実行できるようにします。この問題を回避するには、午前 0 時まで待つのではなく、backfill-redis ジョブを手動でトリガーできます。

コマンドラインインターフェイスから backfill-redis ジョブをトリガーするには、以下のコマンドを実行します。

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

これにより、不足しているデータが Rekor Search UI に戻ります。

Trusted Artifact Signer Operator は設定の変更が適用されない

RHTAS Operator ロジックに潜在的な問題があり、再デプロイ時に予期しない状態が発生する可能性があることが判明しました。この競合状態は、RHTAS リソースから設定を削除し、Operator がそれらのリソースを再デプロイしようとした場合に発生する可能性があります。この問題が発生しないように回避するには、特定のリソースを削除し、キーや永続ボリュームなどの以前のインスタンスの設定を使用してそのリソースを再作成します。RHTAS リソースは、Securesign、Fulcio、The Update Framework (TUF)、Rekor、Certificate Transparency (CT) ログ、または Trillian です。

たとえば、Securesign リソースを削除するには、次のようにします。

oc delete Securesign securesing-sample
Copy to Clipboard Toggle word wrap

たとえば、設定ファイルから Securesign リソースを再作成するには、以下を実行します。

oc create -f ./securesign-sample.yaml
Copy to Clipboard Toggle word wrap

別の OpenShift クラスターに復元した後に、Operator によりコンポーネントのステータスが更新されない

RHTAS 署名者データをバックアップから新しい OpenShift クラスターに復元すると、コンポーネントステータスリンクが想定どおりに更新されません。現在、securesign-sample-trillian-db-tls リソースを手動で削除し、コンポーネントのステータスリンクを手動で更新する必要があります。RHTAS Operator は、削除後、更新された securesign-sample-trillian-db-tls リソースを自動的に再作成します。

バックアップ手順が開始され、シークレットが復元されたら、securesign-sample-trillian-db-tls リソースを削除します。

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

すべての Pod が起動したら、SecuresignTimestampAuthority のステータスファイルを更新します。

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

Trusted Artifact Signer には cosign 2.2 以降が必要

The Update Framework (TUF) リポジトリーの生成方法が最近変更され、異なるチェックサムアルゴリズムが使用されるようになったため、cosign バージョン 2.2 以降を使用する必要があります。RHTAS のこのリリースでは、Trusted Artifact Signer で使用するために cosign バージョン 2.4 をダウンロード できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat