共有写し
おはようございます。 来てくれてありがとう。 ジェームズです。 私はエンジニアで、Dockerで働いています。 私は Docker Scout とDocker公式イメージのセキュリティに取り組んでいます。 一緒にいるのはバスティオン・ゼロのイーサン。 こんにちは、私はBastionZeroのEthanで、この講演の OpenPubkey の部分について話します。
ソーシャルメディアの報道で、発表があったことに気づいたかもしれません。 DockerとBastionZeroは、Linux Foundationと共同で、クールな新しい署名ソリューションを開発しています。 今日はそれについてお話しします。 しかし、最初に、これをDockerの公式イメージのコンテキストに入れてみます。 EthanはOpenPubkeyの詳細に踏み込み、ネットワークが機能しているかどうかのデモを行い、最後に質問する時間があることを願っています。
ちょっとした免責事項として、いくつかのコードを示します。 その一部は存在しません。 一部のコンポーネントが存在しません。 コードは存在します。 ご自宅でお試しいただけます。 おそらくバグだらけでしょう。 それに頼らないでください。 運用環境の準備ができていません。 だからあなたは警告されました。
目次
ドッカーの公式画像
Dockerの公式イメージとは何ですか? ここにいるほとんどの人は、彼らが何であるかを知っているはずです。 DockerCon にいます。 しかし、おそらく最も重要なことは、それが世界最大のオープンソースパッケージのソースの1つであるということです。 会議の冒頭でエイミーが言ったのはそうだと思います。 そこには、多くの、多くの、多くのプラットフォームとアーキテクチャにまたがって 150 リポジトリがあります。
Dockerの公式イメージのサプライチェーンを保護することは、Dockerにとって非常に重要であり、それらを維持するために私たちを支援してくれるコミュニティにとっても非常に重要です。 この文脈に基づいて、サイバーセキュリティおよびインフラストラクチャ機関は、オープンソースに関して焦点を当てるべき2つの重要な領域を特定しました。 1つ目は脆弱性で、カンファレンスの前半では脆弱性と修復、開発者のワークフローについて多くの議論がありました。 そして実際、クリスチャンは今日、別の講演をしています。 だから、それを見てください。
ただし、2番目のビット、つまりDockerの公式イメージに関連するサプライチェーンに焦点を当てます。 Dockerは、私たちが製造しているだけでなく、クライアントに 20 万台のラップトップを出荷しているため、この分野で活動する非常にユニークな立場にあります。 そして、方程式のこの2つの側面を使って何かを始めることができます。
SLSAを抜きにしてサプライチェーンを語ることはできません。 SLSAが何であるかを知らなければ、それはあなたの昼食ではありません。 これは、サプライチェーンをモデル化するためのフレームワークです。 レベルがあります。 これらのレベルを上げることで、セキュリティを段階的に向上させることになっています。 私たちは皆、レベルゼロです。 おめでとうございます。 私たちはそうしました。 しかし、真面目な話、Dockerの公式イメージについては、レベル3に到達しようとしています。 私たちはこのプロセスを実際に経験しているわけではありません。 それは私たちにとって本当に意味がありません。 強化されたビルドエリアでは、すでにかなり多くのことが起こっています。 来歴については多くのことが起こっており、公式画像の中にはすでに出所とSBOMが付いているものもあります。 しかし、今日は署名の部分に焦点を当てます。
署名に重点を置く
ですから、このウサギの穴を掘り下げていくうちに、署名だけの問題ではないことがわかったのです。 誰が署名するのか、なぜ署名するのか、何に署名するのか、がすべてです。 この業界では、GPGのように、人々に署名させるのに非常に成功している署名の例がたくさんあります。 Maven Central Repositoryのすべては、GPGを使用して署名されています。 しかし、誰がその署名を検証しているのでしょうか? これらの署名の価値は何ですか? ですから、検証の問題を解決しない限り、本当の価値は何かという問いを投げかけなければなりません。 さっきも言ったように、検証が大事だと思います。 また、Dockerの公式イメージの場合、検証をオプトインではなくデフォルトにする必要があります。
その結果、究極的には流通の問題です。 証明書、信頼ポリシー、失効、失効した成果物、および証明書を安全な方法でクライアントに入手するにはどうすればよいでしょうか。 また、検証に必要なコードもクライアントに移動する必要があります。 Docker公式イメージのプロデューサーとして、私たちはポリシーを持っています。 私たちは、それらすべてに署名された証明が必要であり、それらすべてに来歴証明が必要であると言いたいのです。 では、どうすればいいのでしょうか?
TUF(トゥフ)
そのためにTUFを使用することを検討しています。 それも一つの方法です。 私はTUFを、iPhoneのようなアプリストアのようなもので、おそらくTUFのような実装を持っていると考えています。 確かに、あなたのブラウザには、CAストアをダウンさせるためのTUFのような実装があります。 ですから、これは、タイムスタンピングサービスとして前方セキュリティをラチェットし、クライアントが常にすべてが最新であることを認識できるようにするための良いパターンです。 そして、そこには仕様があります。 コードもあり、PHP や Python など、さまざまなパッケージ マネージャーで世界中で使用されています。
Dockerのコンテキストでは、これはどのように見えますか? つまり、ボックスとラインです。 左側には、GitのTUFリポジトリであるGitHub Actionがあります。 この考え方は、Dockerスタッフによって管理され、どのキー、ポリシーが何であるか、どの構成証明が存在するべきかを設定するというものです。 これは自動的にレジストリに公開されます。 レジストリは、TUFを表すための素晴らしいネイティブな場所です。 TUF付き。 どこに保管するかは関係ありません。 すべて暗号的に安全です。 したがって、レジストリは良い場所です。
右側には、署名者がいます。 TUFを使用したこの種のフレームワークは、あらゆる署名技術で機能します。 ですから、これはDockerの公式イメージに署名技術を提供するための良い基盤だと考えています。 したがって、Dockerのクライアントは...「docker pull」を実行すると、TUFルートがそのクライアントに埋め込まれているという考え方になります。 「docker pull」を実行すると、最新バージョンの信頼ポリシーがあるかどうかがチェックされますが、署名もチェックされます。 ですから、古い署名を載せることはできますが、署名技術は本当に気になります。
私たちは、非常にシンプルで、説明しやすく、導入しやすい署名技術を求めています。 Dockerの公式イメージを検証するために、追加のトラストポイントは必要ありません。 あなたはすでに私たちのTUFルートを信頼するでしょう。 したがって、別のCAを関与させる必要はありません。 Dockerからの署名を信頼できるはずです。 したがって、安全である必要があります。 現在の暗号を使用する必要があります。 ここでは、独自の暗号を発明するつもりはありません。 私たちは何年も前にそのことを身をもって学びました。 そして、それはオープンであるべきであり、無料であるべきです。 それで、イーサンを引き渡すつもりです。 彼は私たちのソリューションの詳細をあなたに教えてくれます。
オープンパブキー
ありがとう、ジェームズ。 そこで今回は、オブジェクトに署名し、ID で検証するためのプロトコルである OpenPubkey について説明します。 そこで、始める前に、OpenPubkeyが解決しようとしている問題を説明したいと思います。 たとえば、GitHub Action などのワークロードがあるとします。 そして、このワークロードを Alice と呼ぶことにします。 しかし、このコンテキストではユーザーではありません。それはただの作業負荷です。 そして、何らかのイメージを作成し、このイメージに署名し、そのイメージを Alice の署名分析公開鍵と共にレジストリにアップロードします。 ここで、ボブはアリスを信頼し、イメージ、公開鍵、および署名をダウンロードしますが、ボブはこの署名をチェックして、署名されていることを確認したいと考えています。 そして、ボブは質問をします。 公開鍵が署名を検証したとしても、この公開鍵が実際にアリスの公開鍵であることをどうやって知ることができるのでしょうか。 これは、誰の公開鍵でもかまいません。 誰でもここに公開鍵を置くことができます。
そのため、GitHub ActionsでワークロードIDについて話すときは、OpenID Connectについて考える必要があります。 GitHub Actions には、ワークロードに ID を提供し、ワークロードが独自の ID を証明できるようにする OpenID Connect 上に構築された IDP と ID プロバイダーがあります。 そこで、OpenID Connect を使用して、「これが本当に Alice の公開鍵であることをどうやって知ることができるのか」という問題に対するソリューションを構築します。 そのため、OpenPubkey は、OpenID Connect を使用して公開鍵を ID にバインドするためのプロトコルです。
OpenPubkeyの利点は、デバイスからデバイスへとロードする必要がある長期的な署名キーのようなものがある場合、ユーザーがその署名キーを紛失した場合、新しい署名キーを作成する必要があるなど、キー管理の頭痛の種がないことです。 OpenPubkeyを使用すると、署名キーを生成したり、不要になったときに削除したりできます。 IDPに変更を加えることなく機能します。 したがって、今日はGoogle、GitHub、またはMicrosoftにこれを使用できます。 そして、それは安全です。 信頼できるパーティは追加されません。 これは、使用しなければならない新しい CA があると言っているのではありません。 以前と同じように、あなたとあなたの ID プロバイダーだけです。 そして今、DockerでOpenPubkeyがLinux Foundationのプロジェクトとなり、オープンソースで利用できるようになったことを発表できることを本当に嬉しく思います。
OpenPubkey のしくみの詳細を説明する前に、OpenID Connect の背景を少し説明する必要があるので、ここでは例として GitHub Actions を使用します。 そのため、ここでは便宜上 Alice という名前を付けたワークロードがあります。 このワークロードは GitHub Actions IDP に対して認証を行うことができ、これを行うと、IDP は Alice の ID に関する多数の構成証明を持つ ID トークンを作成します。 そして、IDP は IDP 署名の下でこの ID トークンに署名します。 その後、Alice はこの ID トークンを Bob に提示でき、Bob は Alice が Alice であると確信します。 Bob は、公開キーを作成する OpenID Connect の方法である GitHub JWKS URI で公開キーをダウンロードすることで、ID トークンが GitHub Actions 公開キーで署名されていることを確認できます。
仕組み
これをどのように機能させ、これに署名を追加するのでしょうか? ここでは、OpenID Connect の簡易版を紹介します。 基本的にはOpenPubkeyです。 そして、OpenPubkeyによって追加される複雑さを少し説明します。 しかし、基本的にOpenPubkeyは以前と同じです。 しかし、今度はアリスが公開鍵を生成し、公開鍵と署名鍵の鍵ペアを生成します。 そして、ここにはGitHub Actionsの一部であるこのオーディエンス要求があることに注意してください。 アリスは、このaudまたはaudienceパラメータに好きなものを入れることができます。 そこで、パブの鍵をオーディエンスパラメータに入れます。 そして、IDP が ID トークンに署名して返すと、IDP は Alice が提供した値をここに入力します。 そのため、Alice がパブ キーを入力すると、Alice のパブ キーと ID を含む IDP によって署名された ID トークンが存在します。
これで、Alice はオブジェクトに署名できるようになりました。 また、署名されたオブジェクトと共に ID トークンを発行すると、IDP は Alice が使用する pub キーを証明しているため、Bob はそのオブジェクトが Alice の ID で署名されていることを確認できます。 ある意味では、ID トークンは認証局によって発行された証明書のように機能し、ID を公開キーにバインドしていることに注意してください。 ただし、ここには認証局を追加していません。 これは、以前に使用した通常の古いIDPにすぎません。 したがって、これはユーザーIDに対しても機能します。 ここでは詳細には触れませんが、たとえば Google の OpenID プロバイダーを使えば、これを行うことができます。 audience パラメーターを nonce パラメーターに変更するだけで、ここに公開キーが取得されます。
BastionZero では、ワークロード ID ではなくユーザー ID を使用します。 そして、これは非常に強力なツールであり、Googleがハロルドの公開鍵はXであると言っているという署名入りの声明を基本的に得ることができるからです。 では、SSH について考えると、SSH とは何で、SSH パブ キーは何をしているのでしょうか。 彼らは、この公開鍵がそこにあるので、この人は接続を許可されていると言っていますが、それはもう必要ありません。 SSHキーなしでSSHを実行できますが、IDPを信頼してユーザーを識別し、誰もがすでにIDPを信頼しています。 また、これを使用して、ユーザーIDで安全なTLSトンネルを構築します。 また、ネットワーク層とサーバー、エンドホスト、またはK8 クラスタの両方で、IDに期待するパブキーがあることを確認するだけで、IDをチェックできます。 そして、そこで認証されたチャネルまたは安全なチャネルをブートストラップできます。
これにより、信頼せずにロギングとポリシーの適用を実行できることが構築できることの 1 つです。 メッセージの整合性は保護できるため、ロガーまたはポリシー エンフォーサーはメッセージを変更できません。 ただし、そのトラフィックをログに記録してポリシーを適用することはできます。 これについては詳しく述べるつもりはありませんが、講演後に私に聞いてください。 私はそれについて話すのが大好きです。 私たちが作ったものは本当にエキサイティングです。
潜在的な攻撃
ここには緊張感があることに気づいてください。 OpenID は、これらの ID トークンを、秘密にしておく必要がある認証シークレットとして扱い、認証のために公開します。 このパターンの名前はベアラー認証で、認証用のトークンを負担しますが、OpenPubkeyはこれらのIDトークンを公開証明書のように扱います。 パブリック レジストリやインターネット上の任意の場所に署名を付けて公開し、これらを使用して、オブジェクトが ID によって署名されていることを確認します。 ですから、この2つの用途が私たちの緊張感です。
たとえば、OpenPubkey用に公開されたIDトークンを、構成が間違っているOpenID Connect認証サービスに置き換えて、これがOpenPubkey用であるかどうかをチェックしなかった場合はどうなるでしょうか。 必要なすべてのフィールドがチェックされるわけではありません。 GitHubやGoogleが、これがアリスだと言っているのはご存知でしょう。 このような攻撃を防ぐにはどうすればよいでしょうか。
攻撃をもう少し具体的に見てみましょう。 Alice がいて、Alice は以前と同じように ID トークンと割り当てられたオブジェクトを Bob に送信しています。 そして今、邪悪なボブがいて、邪悪なボブがIDトークンを取得し、誤って構成されたOpenID Connectサービスに再生して、「私はアリスです」と言います。 そして、サービスは、GitHubによって署名されています、あなたはアリスです、と言います。
GQ署名
これを解決するための攻撃計画は、IDトークンのセキュリティと暗号化特性を保持しながら、OpenPubkeyに対しては有効であるが、OpenID Connect認証に使用する場合は有効にしないことです。 これを行うために、Alice はここで IDP 署名を、IDP 署名を知っていることの証明 (IDP 署名を知っているという暗号証明) に置き換えます。 したがって、これは実際の署名と同じくらい強力ですが、署名ではなくなります。 そのための手法がGQ署名です。 そこで、IDP 署名を外し、ID トークンの署名を知っているという署名の証明を提供します。
その結果、署名と署名の証明を含むこの ID トークンが、正しく構成されていないサービスに対して再生されると、正しく構成されていないサービスは、OpenID Connect のルールに従って検証を試みますが、失敗し、悪用されないように拒否されます。 しかし、この署名証明は、署名と同じセキュリティ特性を持ち、アリスが実際の署名を秘密にしておくことを可能にします。 アリスは、IDトークンを入手したら、実際の署名を漏洩させないように削除することもできます。
GQ署名(私たちが使っている技術)がどのように機能するかについては、ここでは詳しく説明しません。 1988年に発明されたことは、このかなり有名な論文で指摘しておきます。そして、Newmanは今年、まさにこの問題を解決するためにGQ署名を使用することを提案し、GQ署名の潜在的なユースケースとしてOpenPubkeyとSigstoreを取り上げました。 ですから、私たちがやっていることの多くは、GQの署名に関しては、この論文に基づいています。
ここでは、公開鍵をオーディエンスクレームに単純化するのではなく、単純化していると言ったのを覚えていますか? さて、今、私はそれが少し複雑であるが、それほど複雑ではない方法を説明します。 公開キーのワークロードと共に、ユーザーが署名するアルゴリズムや、Alice が作成したい、または Alice のクライアントが作成したいワークロードなど、追加のメタデータを含める必要があります。
これから行うことは、このメタデータを公開鍵と一緒に取得することです。 すべてをまとめてハッシュ化し、このデータのすべてではなく、実際にハッシュをオーディエンスの要求に提供します。 しかし、Alice の公開鍵はまだそのハッシュにあることに注意してください。 この結果、ID トークンだけでは、公開キーが ID トークンで証明されているかどうかを確認できなくなります。 これらの他のフィールドも必要です。 そのため、これらすべてを 1 つのオブジェクトとしてパッケージ化し、ID トークンが JSON Web 署名であるという事実を利用します。 また、JSON Web 署名では、複数の署名を使用できます。 そこで、Alice の公開鍵を含む対象ユーザーにハッシュする値を含む 2 番目の署名とヘッダーを追加し、これを CIC と呼びます。 名前を気にする必要はありません。 これはクライアント インスタンスの要求を表しますが、公開キーとその他のメタデータが含まれていることを知っておいてください。
PK トークン
これをすべてPKトークンと呼んでいます。 これは、公開キーが ID トークンで証明されていることを確認するために、この機能で拡張された ID トークンです。
そこで、アリスがOpenPubkeyを使ってイメージに署名したいとしましょう。 そのため、最初に行うことは、署名キーを含むキーペアを生成することです。 公開鍵とその他のメタデータを含む CIC を作成します。 次に、CIC をハッシュし、ハッシュを audience パラメーターとして IDP に提供する ID トークンを要求します。 IDP(この場合はGitHub)は、署名付きIDトークンで応答し、IDトークンに新しい署名を作成する前のスライドで説明した内容を使用します。 次に、ID トークンから PK トークンを作成します。 そして、それがIDトークンの追加署名にすぎないことがわかります。 ID トークンは PK トークンの一部です。 これで、署名する準備が整いました。 そこで、彼女は署名したい画像を撮影します。 署名キーで署名して署名 A を取得し、画像、署名、PK トークンをリポジトリにアップロードします。
Dockerの場合、DockerはOpenPubkeyの機能である1回限りの署名を行っています。 これにより、PK トークンは特定のオブジェクトまたは特定の画像に署名するためにのみ使用できます。 これを強制するために、クライアント インスタンス要求を使用し、署名するオブジェクトのハッシュである追加のパラメーター sig を提供します。 そのため、署名キーはそのオブジェクトにのみ使用できます。
Bob が OpenPubkey で署名された署名を検証する場合、Bob は画像、署名、PK トークンをダウンロードします。 次に、Bob は PK トークン内の ID トークンが GitHub によって署名されていることを確認し、対象ユーザーに対して CIC ハッシュを確認し、CIC から Alice の公開キーを抽出し、画像が PK トークン (Bob は Alice であることがわかります) によって署名されていることを確認します。
要約すると、OpenPubkeyはIDPを変更する必要はありません。 OpenID Connect プロトコルを使用するだけですが、キーと公開キーと ID を購入して署名するこの機能で強化されます。 非常に拡張性が高く、さまざまなものを作ることができます。 ここではDockerのユースケースを1つ紹介していますが、例えばMITの学生の中には、この論文を読み、OpenPubkeyとMITのOpenID Connect IDPを使って暗号化されたチャットルームを書いた人もいます。
安全です。 OpenID Connect に新しいパーティが追加されることはなく、GQ 署名により、サービスの設定ミスに対しても、これらの ID トークンが再生されないようにすることができます。 そして、それは便利です。 キー管理の署名はありません。キーはエフェメラルであり、誰かが Google でサインインしたとき、または GitHub Action を持っているときに、ユーザーとワークロードにすでに使用されている OpenID フローを使用します。 詳細については、この論文ではユーザーIDにもう少し焦点を当てていますが、 OpenPubkeyの論文を参照してください。 さて、ジェームズに話を戻します。
デモ
ありがとうございます。 すごい — あれはすっきりしている。 これから行うのは、その小さなフローのデモです。 私がやろうとしていることは、重要な変更を行うことです。 これはすでにDockerイメージとコードに作成されており、変更をコミットし、署名し、GitHubにプッシュしていると思います。 あれはどこにあるの? ここGitHubでは、コミットが入ってくるはずです。 さあ行こう。
それが構築されている間、GitHub アクションがどのようなものか、つまり変更点をお見せします。 そこで、ここに別の buildkit イメージを追加しました。 これは buildkit を拡張する良い方法です。 これは、GitHubのOpenPubkeyに存在するフォークにすぎません。 将来的には、そういった人たちと交渉して、それを組み込んでいきたいと考えています。 そのため、GitHub Action を使用して自動的に署名されます。 何もする必要はありません — ゼロ構成。 鍵の管理も、秘密の保存も、何もない。
GitHub の OpenPubkey 組織にアクセスしてください。 これがコードです。 これは、イーサンによって寄贈されたメインライブラリです。 これは、私があなたに見せようとしている小さな検証CLIプラグインです、またはあなたはおそらく私のキャストバージョンを見ました。 そして、ここにビルドキットがありますので、あちらに行って参加し、問題を提起してください。 ぜひご参加ください。
私のターミナルに戻ります。 「docker verify」できるはずです。 注意深く見ると、IDトークンのすべての詳細が検証されていることがわかります。 GitHub によって署名されていることがチェックされます。 Dockerの組織を確認しました。 間違ったものでこれをもう一度行うと、失敗し、ベーパーウェアではないことを示すはずです。 ああ、そうだ、失敗した。 さあ行こう。
ポリシーについては、まだ作業中です。 クライアントに提示できるポリシー言語が必要です。 したがって、そのビットは未定義です。 現時点では、証明はtoto形式であり、その一部を紹介します。 ちょっと待ってください。
今後の予定
これを少し文脈に当てはめると、どの部分ができて、どの部分ができていないかをお伝えします。 Ethanはそれに触れなかったが、おそらく重要な側面の1つは、GitHub Actionsで生成されるすべての署名ができるように、ここに透明性ログを追加することだろう。 確かに、Dockerの公式ユースケースではそうです。 私たちはGitHubを監視しており、透明性ログに記録しています。 したがって、そこで何か問題が発生した場合、それが発生していることに気付き、修正を試みることができ、TUFを使用していつでも取り消すことができます。
ああ、もう一つ言い忘れました。 そして、これは重要なステップです。 誰がOIDCで作業しているかは誰もが知っているので、これらの公開鍵は期限切れになります。 そして、彼らはそれらを回転させます。 彼らはそれらを定期的にローテーションします。 回転周波数を変更できます。 これはいつも起こります。 そこで、少なくとも最初のドロップでは、Dockerがこれらの公開鍵をTUFリポジトリに配置し、クライアントに配布する計画です。 これはDockerの公式イメージでは機能しますが、誰にとっても機能しない可能性があります。 なぜなら、TUFリポジトリを信頼しているのであれば、公開鍵をそこに入れることができるからです。 そうは言っても、TUFルートに何と署名するつもりですか? OpenPubkeyで署名する必要がありますか? また、OpenPubkeyで署名した場合、それは何を意味するのでしょうか? これはおそらく、公開鍵をそこに入れられないことを意味します。 それらを他のログに保持する必要があります。
しかし、OpenPubkeyは多要素署名のアイデアをサポートしています。 したがって、できることは、別の署名を追加することです。 それで、ねえ、ご存知のとおり、私はGoogleのログインも持っています、そして私たちはそれに副署し、そのリストに3番目の署名を追加します。 そして、それはとてもとてもクールです。
だから、誰もがこれを気に入るわけではないことはわかっています。 好きな人もいます。 そうでない人もいます。 しかし、これは私たちが最初にやっていることです。 署名は画像としてインデックスに添付し、アーキテクチャが不明なインデックスに添付しています。 ですから、ほとんどのツールでそれが機能することを認めてください。 これは、署名が移動することを意味します。 レジストリが壊れることはありません。 そして、それが最終目標ではないことも理解しています。 アーティファクトや参照タイプなど、本当に重要な取り組みが行われていることは理解していますし、間違いなくそれらを取り入れるつもりです。 しかし、これは出発点にすぎません。 また、この作業に関与し、支援するための行動への呼びかけでもあります。 特定のアーキテクチャやイメージに結び付けている場合、それらのシグネチャを見つける方法がないことを理解しています。 これですべてが解決するわけではないことはわかっていますので、ぜひご参加ください。
各構成証明は、そのイメージにレイヤーとして格納されます。 繰り返しになりますが、それは少し厄介なことですが、うまくいきます。 その世界にいる人なら、なぜこのようなアプローチをとったのか、きっと理解していただけると思います。 そこでは、SBOM と SLSA の出所を確認できます。 したがって、ここでの来歴の証明。 もう少し詳しく説明しますが、OPK では OpenPubkey と呼んでいます。 そして、署名をさらに掘り下げます。 ここでは、署名が取り除かれたOIDCペイロードがあります。 OpenPubkeyの署名とGQの証明を手に入れました。 ですから、覚えていれば、イーサンのスライドによく似ているはずです。
そのため、未解決の質問が山ほどあります。 参照とアーティファクトについて言及しました。 もう1つの大きな要因は、ダウングレード攻撃です。 今のところ、誰も署名を検証していないため、それに対する回復力はありません。 しかし、実際には公証人は、タグ自体が署名されているという事実の性質上、ダウングレード攻撃からあなたを保護します。 したがって、この最初のドロップではそれは起こりません。 そうは言っても、影響はおそらく非常に小さく、それに対する解決策があります。 それで、私たちはそれを見ていきます。
もう一つは、OIDCプロバイダーがここで支援することは可能かということです。 そして、ここには本当にチャンスがあると思います。 そして、それは彼らにとっても、私たちにとっても良いことです。 もしこれが一般的な署名方法になれば、とても簡単でオープンなので、WebPKIで公開鍵に署名できるかもしれません。 もしかしたら、公開鍵をログに記録して、利用できるようにできるかもしれません。 もしかしたら、独自の透明性ログを持つことができるかもしれませんし、実際にはそうすべきかもしれません。 ですから、私たちにできることはたくさんあると思います。 そして、先ほども言いましたが、実際にTUFルートをOpenPubkeyで署名する必要がありますか? そして、多要素的なものでできるかもしれません。
これらはこれから起こることです。 透明度ログを追加しています。 DockerのTUFルートを追加します。 これを多数のクライアントに追加して、実際に使用し、署名の検証を開始できるようにする必要があります。 そして、公開鍵ログの問題を解決する必要があります。 これらをTUFに追加する予定です。 チェッカー、モニターを追加して、それを監視できます。 そして、誰でもそれを監視できます。 すべて GitHub にあります。 すべてオープンです。
これが行動喚起です。 是非、参加してください。 とてもエキサイティングだと思います。 そして、Dockerの公式イメージのオープンで特に機能すると考えています。 しかし、この種のテクノロジーを社内に持ち込む場合は、それで良いのです。 外部 CA は必要ありません。 独自の OIDC プロバイダーの上に構築できます。
質疑応答
それでは、ありがとうございます、そして何か質問があれば、今が良い機会です。 どなたかご不明な点がございましたら、
発表ありがとうございました。 では、OpenPubkeyとCosignをどのように比較しますか?
もちろん。 では、OpenPubkeyとSigstoreのCosignをどのように比較するかが問題です。 OpenPubkeyは、公開鍵をIDにバインドする方法であると私は主張します。 そのため、Sigstoreに非常によく適合します。 OpenPubkeyをFulcioに入れることもできますが、SigstoreにはOpenPubkeyにある他のコンポーネントがたくさんあります。 また、署名、透明性ログ、監視など、他のコンポーネントもあります。 そして、そのすべてがとてもクールだと思うのです。 そして、OpenPubkeyで非常にうまく機能するもの。 OpenPubkeyは、完全な署名システムではなく、IDバインディングメカニズムへの公開鍵だと思います。 また、Dockerはより完全な署名システムを構築しており、このID公開鍵バインディングにOpenPubkeyを使用しています。
さらに詳しく
自分に合ったサブスクリプションを見つける
今すぐ専門家に連絡して、Dockerサブスクリプションのコラボレーション、セキュリティ、サポートの完璧なバランスを見つけてください。