Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

リリースノート

Red Hat Trusted Artifact Signer 1.1

Red Hat の Trusted Artifact Signer 1.1.2 のリリースノート

Red Hat Trusted Documentation Team

概要

Red Hat Trusted Artifact Signer のバージョン 1.1.2 の公式リリースノートへようこそ。
このリリースノートでは、Red Hat Trusted Artifact Signer 1.1.2 ソフトウェアリリースに実装された新機能、拡張機能、既知の問題、バグ修正、および廃止予定を説明します。
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

第1章 概要
リンクのコピー

Red Hat Trusted Artifact Signer (RHTAS) サービスは、コンテナーイメージ、バイナリー、Git コミットなどのソフトウェア成果物の暗号化署名と検証を簡素化することで、ソフトウェアサプライチェーンのセキュリティーを強化します。Trusted Artifact Signer は、SecureSign コミュニティープロジェクト の運用準備が整ったデプロイメントを提供します。

Trusted Artifact Signer ソフトウェアのリリースノートには、最新バージョン 1.1.1 の新機能と拡張機能、バグ修正、既知の問題が記載されています。メジャーリリースとマイナーリリースのライフサイクルを通じて公式リリースノートを基に構築されるため、各章の先頭に最新の項目が追加されます。

Red Hat Trusted Artifact Signer ドキュメントは、こちら を参照してください。

第2章 新機能および機能拡張
リンクのコピー

Red Hat Trusted Artifact Signer (RHTAS) のこのリリースで導入されたすべての主要な機能強化と新機能のリスト。

このリリースで追加された機能および機能拡張は次のとおりです。

Rekor のログシャーディング

放置すると、Rekor のログは無制限に大きくなり、全体的なパフォーマンスに影響を与える可能性があります。このリリースでは、スケーリングを管理し、大きなログによって生じる可能性のあるパフォーマンスの低下を最小限に抑えるために、Rekor のログシャーディングを追加しました。シャーディングは、Rekor カスタムリソース (CR) を直接変更して設定できます。Rekor の署名者キーのローテーション用にログシャーディングを設定する方法は、RHTAS 管理ガイド を参照してください。

CT ログのログシャーディング

そのまま放置すると、Certificate Transparency (CT) ログが無制限に大きくなり、全体的なパフォーマンスに影響を及ぼす可能性があります。このリリースでは、スケーリングを管理し、大きなログによって生じる可能性のあるパフォーマンスの低下を最小限に抑えるために、CT ログのログシャーディングを追加しました。シャーディングは、CT ログのカスタムリソース (CR) を直接変更して設定できます。CT ログの署名者キーのローテーション用にログシャーディングを設定する方法は、RHTAS 管理ガイド を参照してください。

Trillian を独立してデプロイする

このリリースでは、他のすべての RHTAS コンポーネントとは独立して Trillian サービスをデプロイできます。RHTAS Operator を使用する、独立したバージョンの Trillian をデプロイできるようになりました。

Trillian から独立して Rekor をデプロイする

以前のリリースの RHTAS の Rekor では、Trillian サービスと Trillian データベースが Rekor と同じ名前空間で実行される必要がありました。この依存性が原因で、複雑な環境やセグメント化された環境に Rekor をデプロイすることはより困難でした。このリリースでは、Rekor を Trillian から独立させ、複雑なインフラストラクチャー設定に適応しやすい方法で Trillian を柔軟に実装できるようになりました。この新しい機能により、API が拡張され、Trillian サービスの接続情報を指定できるようになりました。Securesign リソースの spec.trillian.host および spec.trillian.port オプションに適切な値を指定することで、Trillian 接続情報を指定できます。

Trusted Artifact Signer Operator のプロキシーサポート

OpenShift 環境ではプロキシーを使用して接続が確立されることが多く、これは組織によっては確実に満たす必要のある要件となる場合があります。このリリースでは、RHTAS Operator とオペランドに OpenShift 環境で設定されたプロキシーのサポートが追加されました。

信頼できる Timestamp Authority のサポートが追加される

デフォルトでは、タイムスタンプは Rekor 独自の内部クロックから取得されますが、これは外部から検証することも変更することもできません。信頼できる Timestamp Authorities (TSA) からの署名付きタイムスタンプを使用することで、Rekor の内部クロックが改ざんされるリスクが軽減されます。今回のリリースにより、Rekor の内部クロックを使用する代わりに、信頼できる TSA を設定できるようになりました。

Ingress シャーディング用のカスタム Rekor UI ルートのサポート

このリリースでは、Rekor ユーザーインターフェイス (UI) が OpenShift の Ingress Controller シャーディング 機能と連携するようにカスタムルートを設定できます。

これを設定するには、Ingress および route リソースの externalAccess セクションを変更し、routeSelectorlabels セクションの下に type: dev ラベルを追加します。以下に例を示します。 

...
    externalAccess:
      enabled: true
      routeSelectorLabels:
        type: dev
...
Copy to Clipboard Toggle word wrap

これにより、Ingress Controller は特定のプリセットルート (この場合は dev ルート) のこれらのリソースを識別できるようになります。

Operator が証明書インジェクションによるカスタム CA バンドルをサポートする

このリリースでは、RHTAS Operator は証明書インジェクションを使用してカスタム認証局 (CA) バンドルをサポートするようになりました。OpenShift Proxy または特定の CA を信頼する必要がある他のサービスとの安全な通信を確保するために、RHTAS Operator は、信頼された CA バンドルをマネージドサービスに自動的に挿入します。これらのマネージドサービスは、Trillian、Fulcio、Rekor、Certificate Transparency (CT) ログ、および Timestamp Authority (TSA) です。

追加の CA バンドルを信頼するには、次の 2 つの方法のいずれかでカスタム CA バンドルを含む config map を参照します。

  • 関連するカスタムリソース (CR) ファイルの metadata.annotations セクションに、rhtas.redhat.com/trusted-ca を追加します。
  • spec に trustedCA フィールドを追加して、CR ファイルでカスタム CA バンドルを直接設定します。

Fulcio の CT ログ接頭辞を設定する

このリリースでは、Fulcio の Certificate Transparency (CT) ログ接頭辞を設定する機能が追加されました。以前のリリースでは、接頭辞が trusted-artifact-signer にハードコードされていました。接頭辞を設定可能にすると、柔軟性が向上し、CT サービス内の特定の CT ログをターゲットにできるようになります。Fulcio カスタムリソース定義 (CRD) には、接頭辞を設定できる新しい spec.ctlog.prefix フィールドがあります。

Enterprise Contract は TUF ルートを初期化できる

このリリースでは、ec sigstore initialize --root ${TUF_URL} コマンドを使用して、RHTAS によってデプロイされた The Update Framework (TUF) ルートで Enterprise Contract を初期化できるようになりました。この初期化を行うと、信頼されたメタデータが $HOME/.sigstore/root にローカルに保存されます。

Enterprise Contract ポリシーで特定のイメージのルールを除外するサポート

このリリースでは、特定のイメージダイジェストの Enterprise Contract (EC) ポリシーの volatileConfig セクションに exclude ディレクティブを追加できます。imageRef キーを使用してイメージダイジェストを指定できます。これにより、ポリシー例外が 1 つの特定のイメージに制限されます。

組織レベルの OCI レジストリー認証のサポート

このリリースでは、Enterprise Contract (EC) は、完全なリポジトリーパスの subpath を使用して指定された Open Container Initiative (OCI) レジストリー認証情報をサポートします。一致する認証情報が多数ある場合は、詳細度の順にそれらを試行します。詳細は、コンテナーイメージレジストリーの specification に対する認証を参照してください。

Enterprise Contract ポリシーソースの監査が改善

このリリースでは、各ポリシーソースの Git SHA またはバンドルイメージダイジェストのエントリーがログに記録されます。これにより、Enterprise Contract (EC) の結果の監査が改善され、EC で使用されるポリシーとポリシーデータの正確なバージョンが表示され、再現性が向上します。

Enterprise Contract レポートのデフォルトとしてプレーンテキストを表示

このリリースでは、Enterprise Contract (EC) レポートのデフォルトの出力形式をプレーンテキストに変更しました。プレーンテキスト形式により、EC 結果レポートの読み取りがはるかに簡単になります。

第3章 バグ修正
リンクのコピー

Red Hat Trusted Artifact Signer (RHTAS) のこのリリースでは、次のバグが修正されました。これらの修正に加えて、以前のバージョンで発見され修正された既知の問題の説明もリストします。

ホスト名の設定に必要なオプションが追加された

今回のリリースにより、cli-server および rekor-search-ui のホスト名を設定できるようになりました。RHTAS Operator コントローラーで --cli-server-hostname= HOSTNAME を指定して、ホスト名を設定できます。API を使用してホスト名を設定することもできます。以下に例を示します。 

...
  rekor:
    rekorSearchUI:
      host: HOSTNAME
...
Copy to Clipboard Toggle word wrap

HOSTNAME は、お使いのホスト名に置き換えます。

自己署名証明書を使用する OpenShift クラスターでセグメントバックアップジョブが失敗

自己署名証明書の検証時にセグメントバックアップジョブが失敗したことが原因で、Secure Socket Layer (SSL) 証明書検証エラーが発生していました。この検証が失敗するため、OpenShift の内部 API を使用してジョブはクラスターモニタリングシステムからメトリクスをプルできませんでした。OpenShift の認証局 (CA) の信頼されたバンドルを RHTAS コンテナーに挿入することで、このバグを修正しました。これにより、セグメントバックアップジョブは自己署名証明書を検証し、必要なメトリクスを正常に取得できるようになります。

OpenShift 4.13 でバージョン番号が誤って報告される

この更新の前は、OpenShift Container Platform 4.13 に RHTAS Operator をインストールすると、実際にはバージョン 1.0.1 がインストールされているにもかかわらず、バージョン 0.0.2 と誤って表示されます。このリリースでは、RHTAS Operator のバージョン番号が OpenShift Container Platform 4.13 で正しく表示されるようになりました。

pull-secret の参照が削除された

RHTAS の初期のリリースでは、RHTAS をインストールするためにプルシークレットの入力を求められました。RHTAS の一般提供 (GA) リリース以降、Red Hat OpenShift に RHTAS をデプロイするためにプルシークレットは不要になりました。このリリースでは、RHTAS コードベースから pull-secret への参照をすべて削除しました。

treeID フィールドの変更が Rekor デプロイメントには適用されない

Rekor 設定の treeID フィールドに変更を加えた場合、この変更は Rekor デプロイメントで更新されませんでした。このバグにより、間違ったログエントリーが発生し、Rekor で他の問題が発生する可能性があります。不整合を防ぐために Rekor マネージャーのロジックを修正し、結果として Rekor サービスの信頼性が向上しました。このリリースでは、treeID フィールドを更新すると、Rekor デプロイメントが期待どおりに正しく更新され、正しい status.treeID 値が表示されます。

treeID フィールドの変更は CT ログのデプロイメントには適用されない

Certificate Transparency (CT) ログ設定の treeID フィールドに変更を加えた場合、この変更は CT ログのデプロイメントで更新されませんでした。このバグにより、CT ログの不整合やその他の問題が発生する可能性があります。不整合を防ぐために CT ログマネージャーのロジックを修正し、結果として CT ログサービスの信頼性が向上しました。このリリースでは、treeID フィールドを更新すると、CT ログのデプロイメントが期待どおりに正しく更新され、正しい status.treeID 値が表示されます。

第4章 既知の問題
リンクのコピー

Red Hat Trusted Artifact Signer (RHTAS) のこのリリースで解決された既知の問題:

このリリース RHTAS で見つかった既知の問題のリスト:

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 securesign-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 が起動したら、Securesign と TimestampAuthority のステータスファイルを更新します。

例

$ 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 をダウンロード できます。

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat