第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 リポジトリーの初期化に失敗します。以下に例を示します。
この問題を回避するには、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
oc create job --from=cronjob/backfill-redis backfill-redis -n trusted-artifact-signer
これにより、不足しているデータが 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
oc delete Securesign securesing-sample
たとえば、設定ファイルから Securesign
リソースを再作成するには、以下を実行します。
oc create -f ./securesign-sample.yaml
oc create -f ./securesign-sample.yaml
別の 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
oc delete secret securesign-sample-trillian-db-tls
すべての Pod が起動したら、Securesign
と TimestampAuthority
のステータスファイルを更新します。
例
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
Trusted Artifact Signer には cosign
2.2 以降が必要
The Update Framework (TUF) リポジトリーの生成方法が最近変更され、異なるチェックサムアルゴリズムが使用されるようになったため、cosign
バージョン 2.2 以降を使用する必要があります。RHTAS のこのリリースでは、Trusted Artifact Signer で使用するために cosign
バージョン 2.4 をダウンロード できます。