クラウド環境
クラウドネイティブアプリケーションを標的とするサプライチェーン攻撃に関する分析
今回の記事では、クラウトネイティブアプリケーションのデプロイ工程を支援する目的で近年広く用いられている3種のクラウドネイティブツール「Argo CD」、「Helm」、「Artifact Hub」について解説します。
「コンテナ」や「マイクロサービス」などのサービス分散技術や、それをクラスタ上で管理するシステム「Kubernetes」が広く浸透する中、クラウトネイティブアプリケーションに寄せられる需要と期待はさらに高まりつつあります。これらのアプリケーションの技術の進歩に伴い、企業や組織は、開発プロセスと運用プロセスの連携を促進させる「DevOps（Development、Operations）」方式を取り入れるようになり、コード実装から本番デプロイに至る工程がより迅速に行われるようになりました。しかし、開発者がさまざまなツールやサービス、アーキテクチャを併用する場合、DevOpsの構成も煩雑なものとなり、本番デプロイのように高い権限が行使される場面などにおいては、セキュリティ上の懸念が増大します。こうした課題の一部については、DevOpsの実現手法である「継続的インテグレーションと継続的デプロイ（CI／CD：Continuous Integration and Continuous Deploy）」の機能による対処が可能です。しかし、特に、オープンソースコードやプラグイン、さらにその入手経路も含めて多角的に脆弱性を狙う「サプライチェーン型攻撃」に対しては、先進的に対策を打ち出す姿勢が重要です。そのためにも、各種クラウドネイティブアプリケーションが抱えるセキュリティ上のリスクについて十分に警戒する必要があります。
今回の記事では、クラウトネイティブアプリケーションのデプロイ工程を支援する目的で近年広く用いられている3種のクラウドネイティブツール「Argo CD」、「Helm」、「Artifact Hub」について解説します。各ツールの用途や目的を述べた上で、攻撃者側の視点にも立ち、これらのツールが企業や組織を標的とするサプライチェーン攻撃に不正使用されるリスクを分析します。
さらに、こうした攻撃からシステムを守るために企業や組織で実施できるベストプラクティスや推奨されるセキュリティ対策について解説します。
クラウドネイティブツール「Argo CD」、「Helm」、「Artifact Hub」の概要
以降、各クラウドネイティブツールの基本的な機能や目的について述べます。
Argo CD
Argo CDは、Kubernetes環境下で、宣言的な記述を使用して継続的デリバリの機能を提供します。このツールはGitOpsに相当し、Gitのリポジトリを正当な情報源として使用します。Argoプロジェクトは、200近くの企業や組織をユーザとして持ち、4つのオープンソースプロジェクト「Argo Workflows」、「Argo CD」、「Argo Rollouts」、「Argo Event」で構成されます。このプロジェクトは、当初、ビジネスソフトウェアを提供する「Intuit」によって立ち上げられました。現在では、成長過程（Incubating）のプロジェクトとしてCloud Native Computing Foundation（CNCF）の支援を受けながら、多くの企業や組織によって維持されています。実装はGo言語で記述され、2021年には独立したサードパーティによるセキュリティ監査を受けました。また、CNCFの技術諮問グループ（TAG：Technical Advisory Group）によるセキュリティ評価が行われました。この評価結果については、こちらをご参照ください。
Artifact Hub
Artifact HubはCNCF発の比較的新しい、叩き台状態（Sandbox）のプロジェクトであり、Kubernetesのアーティファクトを集中的に管理して検索する機能を提供します。該当するアーティファクトとしては、上述のHelmチャートの他、Kubernetesの制御ツール「kubectl」用のプラグイン、セキュリティツール「Falco」のルール定義などが挙げられます。また、Artifact Hubは、Docker HubのKubernetes版と見なすこともできます。現在提供されている殆どのプロジェクトはGibHubリポジトリに配置されていますが、Artifact Hubを用いることにより、アーティファクトをより一層スムーズに検索することが可能です。また、Artifact Hubの統計ページには、各種パッケージ、リリース、リポジトリに関する情報が記載されています。
攻撃シナリオ
上述したクラウドネイティブツールが抱えるセキュリティリスクについて、攻撃者の視点も含めて分析するため、想定される攻撃のシナリオを複数検討しました。各攻撃シナリオについて、サイバー犯罪者が利用する脆弱性や、企業または組織が実施できるセキュリティ対策について分析します。以降、各攻撃シナリオの内容と分析結果について解説します。
Argo CDへの不正アクセス
Argo CDにおける重要なセキュリティ課題の1つは、ポータルWebサイトへの不正アクセスを阻止することです。そのため、このポータルサイトはインターネットに公開するべきではありません。インターネットに公開した場合、攻撃者は何らかの方法で認証情報を窃取してポータル内部に侵入し、Kubernetes（K8s）のクラスタ上に、暗号資産マイナーをはじめとする不正なアプリケーションをインストールする可能性が懸念されます。実際に、検索サイト「Shodan」で確認したところ、数十ほどのArgo CDサーバがインターネット上に公開され、直接アクセスが可能な状態になっていることが分かりました。
Argo CDをはじめとするクラウドネイティブアプリケーションを使用する企業や組織が増え続ける中、こうした不用意な露出を最小化するデリバリ手段が取られない限り、危険な状態に置かれたサーバの数が、これから先、指数関数的に増え続けるであろうことは想像に難くありません。これは憂慮すべきことであり、何らかの特別な対策を打つことが望まれます。今回の検索では、ヒットした母数が少なく、検索条件も単純な文字列一致でした。潜在的なセキュリティリスクについてより詳細に分析するため、さらに別の検索エンジンも使用しました。
検索サイト「Censys.io」で「argocd」の文字列を検索したところ、約4,000ものサーバがヒットしました。調査したところ、これらのほとんどは、実際にKubernetes上で稼働しているArgo CDサーバであることが判明しました。
ビルドやデプロイのパイプラインを構成する他のDevOpsツールと同様、Argo CDのサーバは一般公開されるべきではなく、強力な認証情報と認証方式によって守られるべきです。今回調査したArgo CDサーバの中には、インターネット上に公開され、ユーザ名とパスワードだけで認証できるものが見られました。これは憂慮すべきことです。Kubernetesのクラスタ上にアプリケーションをデプロイするインターフェースは、Web上に公開されるべきではありません。全てのアクセス・イベントは監視され、一貫したセキュリティ方針が遵守されるべきです。
Argo CDのドキュメントによると、デフォルトアカウントのユーザ名は「admin」、パスワードは、大文字、小文字、数字、ハイフンから構成されるランダムな16文字で定義されます。このランダム文字列は、Go言語のライブラリ「crypto/rand」を用いたセキュアな方式によって生成されます。図5に、初期パスワードの生成に対応するコードを示します。取得元はこちらをご参照ください。
図5のコードで生成された初期パスワードは、Kubernetesのクラスタ内にSecretオブジェクトとして格納されます。KubernetesのSecretオブジェクトは、本来、機密情報を格納する意図で設計されたものです。しかし、デフォルト設定での動作は、元のデータをbase64でエンコードして、それをデータ格納用コンポーネント「etcd」に平文のまま保存するだけです。この方式は、残念ながら、安全とは言い難いものです。そのため、Secretsオブジェクトを安全に使うためには、暗号化の仕組みを別途追加で有効化する必要があります。
以上のことを踏まえると、Argo CDのadmin用パスワードを取得するには、K8sのクラスタにアクセス可能で、かつ、適切なロール別アクセス制御（RBAC：Role-Based Access Control）の権限さえ所持していれば十分、ということになります。Argo CDの公式ドキュメントによると、adminパスワードを変更後、初期パスワードを格納するSecretオブジェクトはすぐに削除するように、注意喚起されています。しかし、クラスタ管理者が内部のデータにアクセスしない限り、初期パスワードが本当に正しく削除されたかどうかを確認することは難しいでしょう。「etcd」に格納された情報を保護する方法について、トレンドマイクロの資料「The Basics of Keeping Kubernetes Clusters Secure」をご参照ください。
取得元はこちらをご参照ください。
Argo CDへの不正なHelmチャートの取り込み
Argo CD上で完全なアクセス権を持つユーザは、デフォルトでは先に挙げたadminのみです。そのため、攻撃者は、図4のようなWebインターフェースからブルートフォース攻撃を行い、adminユーザの認証情報を窃取する可能性があります。なぜなら、こうした攻撃に対する防御策はArgo CD自体のネイティブ機能としては提供されていないためです。adminの認証情報を窃取した攻撃者が次に取る行動は、標的企業がArgo CDサーバ内に設定している認証方式によって異なります。例えば、ローカルユーザアカウントを設定している場合もあれば、Microsoft、Okta、Googleなど各種サービスとの間でシングル・サイン・オン方式（SSO：Single Sign-On）を設定している場合もあります。また、Argo CDのadmin認証情報を得た攻撃者は、RBACの設定を操作することにより、各種Argo CDリソースへのアクセスを許可、または禁止することも可能になります。
攻撃者がArgo CDにアクセスできることは、同時に、Argo CDが管理する環境にもアクセスできることを意味します。本来、Kubernetesクラスタのコンテナ内でアプリケーションの作成、変更、削除を行うためには、それに該当する権限が必要になります。しかし、Argo CDへのアクセス権を取得した攻撃者であれば、不正なHelmチャートやGitHubリポジトリの内容を、Argo CD経由でデプロイすることが可能になります。結果として、Kubernetesクラスタに、攻撃者の目的であった不正なアプリケーションが展開されることになります。以降、これが実環境でどのような影響を及ぼすのかについて、解説します。
まず、暗号資産「Monero」をマイニングする目的で、攻撃者がArgo CDのインスタンスに既に侵入した状況を想定しましょう。この時、仮にその攻撃者が、K8sやHelmチャートに関する知識をほとんど持っていなかったとしても、すでに公開されているアプリケーションをArtifact Hubから取得して不正使用できる可能性があります。実際にMoneroをマイニングする想定で、Artifact Hubで「cryptocurrency」を検索しましたが、検索結果はごく少数しか得られませんでした。そこで今回は、Monero用のマイニングツールとして知られる「XMRig」を用いることとしました。
取得元はこちらをご参照ください。
マイニングツールのHelmチャートが見つかったこの時点で、攻撃の準備が整いました。攻撃者は、Argo CDを経由して不正なアプリケーションをKubernetesクラスタ上にデプロイすることができます。具体的には、Argo CDにログイン後、アプリケーションの新規作成メニューを開き、図7で示したMoneroのHelmチャートが置かれているGitHubリポジトリを、アプリケーションソースとして指定します。同期化処理が完了後（Sync状態になる）、暗号資産マイニングを行うポッドが対象クラスタに自動でデプロイされます。
図9に、KubernetesクラスタとArgo CDの同期完了後に、Moneroアプリケーションに関連して生成されたKubernetesオブジェクトを示します。
以上に述べたシナリオは、先に述べたArgo CDのadminユーザに関する脆弱性が、実際にどのような攻撃に繋がるかを示す一例です。もちろん、Webポータルを経由したアプリケーションのデプロイ操作から、クラスタ上で生成されるネームスペースに至るまで、クラスタ管理者が攻撃に気づくきっかけとなる「警戒フラグ」も存在するでしょう。しかし、攻撃者は、こうした警戒フラグを容易にクラスタ管理者の目から隠すことができます。
また、以降で述べる通り、攻撃者は、この警戒フラグを正規アプリケーションによる挙動の一部として偽装することも可能です。
Argo CDが参照するGitHubリポジトリの乗っ取り
Argo CDでは、Gitリポジトリを正当な情報源として参照します。そこで今回、正規アプリケーションの管理者が使用するGitリポジトリの認証情報が攻撃者に窃取された場合を想定して、さらに踏み込んだ分析を行いました。興味深いことに、これに近いことは、すでに起きています。実際に、パッケージ管理システム「npm」には、失効したドメインのメールアドレスで数千のアカウントが登録されていることが報告されています。さらに、GitHubのセキュリティ対策チーム（SIRT：Security Incident Response Team）によると、2020年に発生したフィッシング攻撃において、多くの開発者のGitHub認証情報が標的として狙われていました。
こうした状況を踏まえると、攻撃者は、企業が管理するK8sクラスタに不正なアプリケーションをインストールさせる目的からGitHubリポジトリの認証情報を窃取する可能性があります。認証情報を窃取した攻撃者は、GitHubリポジトリの内容を、攻撃用の不正なコードで置き換えます。この後、当該の不正なコードがArgo CDを経由してクラスタ上にデプロイされることになります。不正なコードとは、前述の攻撃シナリオ（Argo CDへの不正なHelmチャートの取り込み）における暗号資産マイナーの場合もあれば、Kubernetes自体に居座らせるバックドア型マルウェアの場合もあります。これが実際にどのように起こるのかについて、以降、詳しく解説します。
今回の攻撃シナリオを模擬的に実行するため、仮のGitHubリポジトリを新規作成しました。このリポジトリは、K8sクラスタにアプリケーションをArgo CD経由でインストールする際に用いられる、正規の有名なものと想定します。ここで、次のことを考えてみる価値があります：Helmチャートの管理者は、セキュリティ対策を通して、どこまで確実に自身のアカウントを保護し、作成するソースコードの真正性を維持できるでしょうか？
図13を見ると、Argo CDからアプリケーションをデプロイするために、Helmチャートを使用できることが分かります。今回のHelmチャートは、攻撃シナリオを模擬的に検証する目的上、偽（Fake）の名前を冠しながらも、中身としては無害なものを使用しました。しかし、もし、その中身がクラスタからSecretオブジェクトを窃取する不正なアプリケーションであった場合は、どのようなことが起こるでしょうか。ここで、次のことを考える価値があります：ソフトウェア開発者は、使用するHelmチャートの出所や正当性について、どこまで確実に、一貫性を持って確認できるでしょうか。一つ言えることは、この確認作業を怠ると、Helm チャート自体に異常がない限り、当該のアプリケーションは何の問題もなくクラスタ上にインストールされてしまいます。
上記のシナリオに関連して、GitHubのアカウントを乗っ取った攻撃者が、偽のHelmチャートをさらに更新する、というケースも考えられます。この場合、Argo CDが監視するリソースに変更が入るため、一旦、アプリケーションは同期がとれていない(Out of Sync)状態になります。しかしその後、再度、自動でデプロイが行われ、同期状態（Sync）に戻ります。この結果、攻撃者による偽Helmへの修正が、K8sクラスタ上にもそのまま自動で反映されることになります。
HelmチャートリポジトリおよびArtifact Hubの管理者を偽称
Artifact Hubでは、誰でもHelmチャートなどのアーティファクトを登録できます。この利便性を逆手に取った2つの攻撃手段について解説します。
- 第一の手段として、攻撃者は、正規のHelmチャートと類似する名前で、不正なHelmチャートを登録する。このタイポスクワッティング（Typosquatting）と呼ばれる手口により、ユーザは、正規のHelmチャートではなく、不正な方を気付かずにダウンロードしてしまう可能性がある。
- 第二の手段として、攻撃者は、Helmチャートを多数登録している著名なArtifact Hubユーザと類似する名前で、自身のアカウントを登録する。両者の名前にあるわずかな差異に気づかなかったユーザは、攻撃者のHelmチャートを正規のものと誤認識してダウンロードしてしまう。
偽称による攻撃シナリオ1
図14は、コード静的解析ツールである「SonarQube」をArtifact Hubで検索した結果ですが、この中で、ダウンロードしても安全なものはどれでしょうか。それぞれのHelmチャートの信頼性をどのように評価すべきでしょうか。Artifact Hubの検索結果として表示される各アーティファクトの信頼性を計る上で役立つ指標について、下記に記載します。
- Verified Publisher：当該アーティファクトの投稿者は、対象リポジトリを所有していることを表す。つまり、Artifact Hubに当該アーティファクトを投稿した者は、そのアーティファクトが置かれているGitHubリポジトリの所有者であることを表す。所有者であるかの判定処理は自動であり、YAMLファイル「artifacthub-repo.yml」に基づいて投稿者とリポジトリ所有者の一致度具合を検証する。判定処理の詳細は、こちらをご参照ください。
- Official：投稿者は、当該のパッケージでデプロイされるソフトウェアを所有していることを表す。所有者であるかの判定は手動で行われ、当該の投稿者は上記「Verified Publisher」でなければならないなど、幾つかの要件が存在する。判定処理の詳細は、こちらをご参照ください。
- Image Security Rating：Artifact Hubが採用するアプリケーションのイメージ解析ツールから算出されたセキュリティランクを表す。この指標は、オープンソースツールの「Trivy」によって取得される。当該の解析ツールは1時間に2度起動し、頻繁にセキュリティレポートが作成される。Image Security Ratingは信頼性を計る上で有効な指標であるが、他の指標も併せて考慮の上、いかなるセキュリティ上の問題点も見逃さないように警戒する必要がある。トレンドマイクロは、クラウド上の脅威とセキュリティ推奨に関する調査「Linux Threat Report 2021 1H」において、公式Docker Hubイメージの中でも特に著名な上位10個について、そのいずれもが、重大なセキュリティ懸念事項を最低1件抱えていることが判明した。Image Security Ratingの詳細については、こちらをご参照ください。
- Ownership Claim：ユーザは、Artifact Hubにアーティファクトを自由に追加できるため、自身で所有しているものが他者によって登録されるケースもある。自身のリポジトリがすでに登録されていた場合は、オーナーシップを主張する手続きをとることができる。この手続きでは、「owners」項目を記載したYAMLファイル「artifacthub-repo.yml」を、当該リポジトリに追加する必要がある。Artifact Hubのドキュメントによると、オーナーシップを認められる要件として、当該YAMLファイルに記載されたownersリストに自身が含まれること、さらに、記載されたメールアドレスが、Artifact Hubのログインに使用するものと一致することが挙げられる。詳細については、こちらをご参照ください。
図14で一番左上のHelmチャートには「Official」タグが付与されているため、一見すると、正規なもののように見えます。しかし、Image security ratingは「F（重大な脆弱性あり）」であり、左側の上から3番目と比べて、星の数が少ないことが分かります。従って、これら2つの指標を併せて考えた時、左上のHelmチャートが必ずしも正規なものとは限らないでしょう。このように、1つのツールに対して複数の判断材料があると、最終的な判断に至るプロセスは複雑なものとなり、誤りを犯すリスクも発生します。これは、サイバー攻撃者にとって都合の良い状況と言えます。同様に、攻撃者が自身でSonarQubeの一部を改変したものをHelmチャートにまとめて、それをArtifact Hubに登録する可能性も考えられます。実際に、このような手口はGitHubやDocker Hubの他、Maven、npmなど各種パッケージマネージャにおいて頻繁に発生しています。
Docker Hubを使用する際は、検索結果から安全なものを見抜く判断力が求められます。そして、Artifact Hubの検索についても、全く同様のことが言えます。システム開発者は、自身の環境にダウンロードしてインストールするファイルが信頼できる正規のものであるかどうか、注意深く検討する必要があります。例として、「Official」、「Verified Publisher」などのタグを確認することによって、不正なアーティファクトをダウンロードするリスクを低減できます。
偽称による攻撃シナリオ2
偽称による第2の攻撃シナリオとして、ユーザ「joaquinito2051」を例に挙げて解説します。当該ユーザは、2022年4月18日時点で1,000を超えるHelmチャートをArtifact Hubにアップロードしていましたが、その中で、自身が所有しているものは1つもありませんでした。つまり、当該ユーザは、GitHub上、いずれのHelmチャートの所有者でもなければ、管理に関わっているわけでもありません。さらに、この名前を持つユーザは、GitHub上には一度たりとも存在していなかったことが分かりました。
2022年4月18日時点、取得元はこちらをご参照ください。
2022年4月18日時点、取得元はこちらをご参照ください。
Artifact Hubのユーザおよび投稿者とGitHubのユーザに直接的な関係はありませんが、GitHubのユーザアカウントを使ってArtifact Hubにログインすることは可能です。
GitHubのアカウントでArtifact Hubにログインできることを踏まえ、まず、「joqauinito2051」の名前でGitHub側に新規アカウントを作成し、そのアカウントを使用してArtifact Hubへのログインを試みました。
しかし、このログインの試みは失敗しました。ユーザ名「joanquinito2051」のアカウントがArtifact Hub上ではすでに登録されていたためです。そこで、偽称の代替手段として、今回GitHubに登録したユーザ名のうち、「2051」の「0」の部分を、大文字アルファベットの「O」に変更しました。この違いは、目視ではほとんど気付かないでしょう。名前の変更後は、当該のGitHubアカウントを使用してArtifact Hubにログインできるようになりました。
この次に攻撃者が取る行動は、リポジトリを追加して、不正なHelm チャートをそこに投入することです。後は、不用心なユーザによってその不正なファイルがダウンロード、インストールされるのを待つだけです。インストールの実行後、攻撃者は、当該ユーザの環境に侵入して、リソースを使用するなどの不正行為に着手するしょう。ただし、今回の検証は、ここまでとします。これ以上先の段階に進めた場合、正当性は確認できないものの投稿数の多い当該Artifact Hubユーザが公開しているアーティファクトを実際に偽称することとなり、他のArtifact Hubユーザに対しても好ましくない影響を与えてしまう可能性が懸念されるためです。
セキュリティに関する検討事項
今回は、3種のクラウドネイティブツールに焦点を当て、さまざま攻撃シナリオに関する分析を行いました。以降では、この分析結果に基づき、各ツールを安全に使用する上で実践できるベストプラクティスや、注意すべきセキュリティ事項について解説します。
Argo CDのセキュリティ監査と自己検査
既に述べている通り、Argo CDを一部として含むArgoプロジェクトは、2021年3月に独立したサードパーティによるセキュリティ監査を受けました。最終監査報告と技術詳細については、こちらをご参照ください。また、CNCFのセキュリティ技術諮問グループによるセキュリティ審査も実施されました。さらに、2022年初頭、Argo CDプロジェクトは、初のゼロデイ脆弱性への対応も実施しました。一連の対応は、Argoのコミュニティがセキュリティ対策をいかに重要な課題として受け止め、取り組んでいるかを示すものです。
以上を踏まえ、企業や組織の中でシステムの開発と運用（DevOps）に携わるチームは、Argo CDを使用する際に下記のセキュリティ事項について注意することを推奨します。
- メモリ内データベースを提供する「Redis」では、デフォルト通信プロトコルとして、暗号化されていないHTTPが採用されている。以前の調査により、8,000を超えるRedisサーバがクラウド上に公開され、暗号資産マイニング用のリモートコード実行（RCE：Remode Code Execution）を行う目的で不正使用されていることが判明した。ArgoはデータキャッシュにRedisを使用しているため、Redisが攻撃の被害を受ければ、Argo CDにも影響が及ぶ可能性がある。
- Argo CDをクラスタ上にデプロイして、さらに新規ユーザを追加した後は、デフォルトで用意されていたadminユーザを削除することを推奨する。この対応は、Argo CDのドキュメントでも言及されている。
- APIエンドポイントにログイン可能なIPアドレスが存在しないようにする。
繰り返しになりますが、企業や組織は、Argo CDをデプロイする際に上記の事項に注意することで、攻撃による被害を抑え込むことができます。
Helmのセキュリティ監査
Helmのセキュリティ監査は、直近で2020年の8月に実施されました。サードパーティ製のHelm チャートを利用する際は、その出所と正当性について確認することが重要です。また、Helmには、署名とチェックを手軽に行う仕組みが備わっています。上記のことは、Helmのドキュメント内でも、詳しく述べられています。企業は、自身で所有していない、または信頼性が担保されていないコードをシステム内で実行するべきではありません。また、信頼できる正規なHelmチャート以外は、デプロイするべきではありません。
Artifact Hubの課題
Artifact Hubは3種のクラウドネイティブツールの中で最も新しく、かつ、サンドボックス状態ということもあり、Docker Hubが最初にリリースされた頃と同様の課題を背負っています。先にも示した通り、セキュリティを確保するためには、正しいHelmチャートを探し、その出所について確認する必要があります。画面上に表示されるタグは信頼性を計る指標として役立ちますが、それで全ての問題が解決するわけではありません。攻撃者はこうした課題の存在に目を付け、正規のHelmチャートと似た名前で不正なHelmチャートを作成し、それをユーザにダウンロードさせようと画策する可能性があります。こうした攻撃を防ぐためには、ユーザ側での努力が不可欠です。Artifact Hubで公開されているHelmチャートを使用する前に、よく注意を払って、その正当性を確かめるべきです。Artifact Hubのパッケージセキュリティ報告ページでは、アーティファクトを安全に検索する上で役立つ情報が網羅されています。現状、開発者は「Official」タグと「Verified Publisher」タグが付与されたHelmチャートのみを使用することを推奨します。投稿者については、自身が投稿するアーティファクトが漏れなくスキャン対象となるように設定することを推奨します。
その他の推奨事項
サイバーセキュリティの改善に向けて企業が行える実践的な取り組みの1つとして、署名と検証の仕組みをビルドやデプロイのパイプラインに組み込むことが挙げられます。これは、コミット時の記録や、生成されるコンテナ・イメージに対して署名を施すことで実現されます。開発者は、アーティファクトの正当性を継続的に担保するために、Helmチャートの署名手続きを利用できます。その際に有望なツールとして、「Docket Content Trust」と「cosign from sigstore」が挙げられます。全体的な目標は、許可されたユーザのみがリポジトリを変更できるようにすること、そして、提供元からエンドユーザに向けて、アプリケーションを安全に配布するルートを確立することです。
トレンドマイクロのソリューション
Trend Micro Cloud One™ Container Securityは、ビルドパイプラインにおけるコンテナ・イメージとレジストリの自動スキャン機能を提供します。Container Securityは、開発チームと運用チームの双方に寄り添った設計に基づき、プロジェクト内で依存関係にあるオープンソースに潜むマルウェアや機密情報、鍵情報、コンプライアンス違反、そして脆弱性などの脅威を、早い段階から迅速に検知します。トレンドマイクロによる業界最先端のルールを適用することにより、直接インストールされたアプリケーションと、パッケージマネージャでインストールされたアプリケーションの双方から脅威を検知します。さらに、Snykオープンソース脆弱性データベースに基づく脆弱性の早期検知と緩和措置の機能により、開発チーム側での作業は、より一層スムーズなものとなります。Container Securityは、アプリケーションの継続的デリバリ機能を本番環境に適用可能な水準でDevOpsチームに提供します。これにより、ビルド・サイクルに影響を与えることなく、ビジネス要求を満たすことが可能です。
参考記事：
• 「Abusing Argo CD, Helm, and Artifact Hub: An Analysis of Supply Chain Attacks in Cloud-Native Applications」
By: Magno Logan
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）