オンデマンドトレーニング

コンテナセキュリティとDocker Scout

 

写し

これがDocker Container Security and Scoutです。 このプレゼンテーションでは、運用イメージとコンテナを含む、イメージとコンテナをセキュリティで保護する方法について説明します。 イメージの依存関係、構成、またはラントップ オプションを変更すると、アプリケーションの動作に影響を与える可能性があります。 本番環境にデプロイする前に、変更を十分にテストしてください。

 

目次

 

コンテナセキュリティ (0:23)

このセクションでは、コンテナのセキュリティについて説明します。 Linuxコンテナと、Linuxプロセスを保護する方法、および最も安全なイメージを作成する方法に焦点を当てます。 最初に話すのは、rootユーザーと非rootユーザーです。 Root は、コンテナのデフォルトユーザーです。 これを非 root ユーザーに変更でき、特に本番環境でコンテナを実行している場合は変更する必要があります。 これは、いくつかの異なる方法で行うことができます。 これは、Dockerfile と Docker run コマンド、または Docker Compose で行うことができます。 ここでは、最初のオプションとして、Dockerfile内にユーザー(myuser)を追加しています。 つまり、Dockerfile が実行されると、その root ユーザーは、その特定のコンテナーを実行するときに指定した myuser に変更されます。 ここでも run コマンドで同じことを行うことができます。 Docker の -user を実行すると、グループ ID とその中で指定されたユーザー ID が表示されます。 または、下の例では、Compose ファイルを見ることができます。 この Compose ファイル内では、プラグインされている環境変数のユーザー ID で指定されているユーザーを確認できます。 一番下にあるのは、ユーザーの指示とそのさまざまな使用方法について詳しく説明したブログですので、ぜひご覧ください。

user コマンドで実行できるすべての種類の操作を正確に示すためのもう 1 つの例を示すために、Docker init が add user コマンドを生成する方法を次に示します。 ここでは、これに追加されているさまざまなオプションがたくさんあることがわかります。 パスワードを無効にしています。 家はないと言っているのです。 ログインがないと言っています。 シェルはありません。 家を作る必要はありません。 これに指定するユーザーIDは、必要に応じてadd userコマンドに追加できるすべてのオプションです。 必須ではありませんが、この方法で行うことで、イメージとコンテナのセキュリティを強化するのに役立つことは確かです。 次は、読み取り専用コンテナとLinux機能です。 デフォルトでは、コンテナを実行しても、実行中にそのコンテナのファイルシステムに書き込むことができます。 あなたは入ってそれに変更を加えることができます。 アプリケーションは、実行中に変更を加えることができます。 本番環境では、それを望まない場合があります。 本番環境では環境を不変にしたいかもしれませんが、それは理にかなっています。 これを行うために、私たちが行っているのは、読み取り専用機能を実行するオプションを提供することです。 イメージを読み取り専用にすると、イメージに書き込むことができなくなります。 もちろん、この問題の問題は、アプリケーションが動作中に書き込む必要があるということです。 たとえば、一時ディレクトリへのもの。 それに書き込むことができる必要があるかもしれません。 そのため、読み取り専用フラグを使用すると、tempfs と呼ばれるものを通じてそれを行うことができます。 つまり、tempfsが行っていることは、ファイルシステムに書き込む代わりにメモリに書き込むことを許可することです。 つまり、そのコンテナが停止すると、その tempfs メモリ領域は消えます。 特定の時点では保存されません。 しかし、一時的に物事を書き出すだけであれば、それは問題ではありません。 したがって、デフォルトでは、読み取り専用フラグを使用すると、一時ディレクトリは tempfs でカバーされます。 しかし、その特定のディレクトリ構造にも書き込む必要がある別のものがある場合はどうでしょうか。 まあ、自分でtempfsを使うこともできます。 tempfsについては、ここにリストされているリンクに移動し、tempfsを使用する他のディレクトリも指定できます。 さて、あなたが物を保存するためにメモリを使用している場合は、メモリの制約を念頭に置く必要があることを覚えておいてください。 メモリが不足すると、実際に何かを書き込むためのスペースが不足することになります。 スライドのもう1つの要素は、Linuxの機能です。 コンテナは Linux プロセスであるため、他の Linux プロセスと同様に Linux 機能も備えています。 右側に表示されている場合は、デフォルトで割り当てられている機能です。 これらの機能の一部は、このプロセスを本番環境で実行できるようにしたいものではないかもしれません。たとえば、グループIDを強制終了したり、設定したり、ユーザーIDを設定したりします。 したがって、機能を削除するか追加するかを決定できます。 左側に–cap-drop=ALLと書かれています。 これが行っているのは、本番環境でLinuxの機能をすべて削除したくないというものです。 また、これら以外にも、必要に応じて追加できる機能もたくさんあります。 また、必要に応じて、削除または追加する個々のものを選択できます。 ここの2番目のリンクには、すべての異なる機能のリストがあり、追加または削除する機能を決定できます。

 

シークレット&コンテナ (5:02)

さて、シークレットとコンテナについて少しお話ししましょう。 コンテナは、多くの場合、実行するためにシークレットにアクセスする必要があります。 ユーザー名やパスワードなど、TLS証明書やキー、SSHキー、データベースやその他の内部サーバーの名前やアドレスなどの重要なデータなど、さまざまなものがあります。 では、これらの秘密にアクセスする必要がある場合、その秘密はどこから入手するのでしょうか? さて、ここにはさまざまなオプションがあります。 いくつかの悪いオプション、1つの大丈夫なオプション、そして1つの良いオプション。 ソースコード内のシークレットを見つけることができるので、ソースコードにアクセスできる人なら誰でもそれを見ることができます。 また、シークレットを変更する必要がある場合は、アプリケーションを再構築する必要があります。 それらを画像に直接組み込むことができるので、画像にアクセスできる人なら誰でも見ることができます。 また、シークレットを変更する必要がある場合は、イメージを再構築する必要があります。 実行スクリプトに格納して、ソース管理にバックアップすることもできます。 これで、イメージを変更してもイメージを再構築する必要がなくなりましたが、ソース管理にアクセスできるユーザーは引き続きイメージを表示できます。 それを環境変数に入れることができます。 これは、秘密やそのようなことを行う方法としてよく示されます。 しかし、環境変数を配置したり、たとえば、これがベンダーにダンプされたりすると、環境変数として表示されます。 また、そのマシン上のすべてのプロセスで使用できます。 ですから、それも本当に良い選択肢ではありません。 それをファイルに入れて、プロセスが秘密を取得する場所を認識できるようにすることもできますが、その運用マシンで使用できます。 これは問題ありません。 したがって、秘密をどこで入手するかを知っているのはプロセスだけです。 しかし、マシンにアクセスできる人なら誰でもその秘密を見つけに行くことができます。 そして最後に、秘密の保管庫があります。 つまり、これはシークレット管理アプリケーションになります。 そして、シークレットを要求しているプロセスのみが、そのボールトから実際にシークレットにアクセスできます。 これは、セキュリティの高い環境でシークレットを処理する場合に推奨される方法です。

さて、その特定のプロセスの実行方法について少しお話ししました。 では、そのイメージの構築について少しお話ししましょう。 本番環境またはセキュアタイプの環境のイメージを構築する際に考慮すべき点は何ですか? まず、その画像に写っているものを制限したいと考えています。 そのため、開発ツールと製品イメージを制限したいと考えています。 本番環境でアプリケーションを実行するために必要なものだけが必要です。 つまり、ソースコードは必要ないということです。 IDEは必要ありません。 コンパイラは必要ありません。 デバッガは必要ありません。 デプロイできないビルドアーティファクトは必要ありません。 基本的に、開発者が本番環境で必要とするツールは必要ありません。 その運用イメージには、そのアプリケーションを実行するために必要なものだけを含める必要があります。 OSツールについても同じことが言えます。 コンテナがアプリケーションを実行するために必要なものだけを持つべきだと言っているなら、それはパッケージインストーラーやエディター、Curlのようなネットワークツール、さらにはPingのようなもの、特にSudoのようなものは必要ないことを意味します。

アプリケーションを実行しているだけであれば、そのようなものは必要ありません。これは、私たちのプロダクションイメージが行うべきことです。 これでどこまで行けるのか? さて、ベースイメージをさらに制作し続けることができます。 私たちは、ほとんど含まれていない特定のディストリビューションレスベースイメージに移動することもできますし、スクラッチイメージと呼ばれるものまで行くこともできます。 スクラッチ画像にはほとんど何も入っていないので、そこから始めることができます。 これまで、ベースイメージからものを削除して、アプリケーションを小さくすることについて話してきました。 これは素晴らしいことだと言っていますが、ある時点で、アプリケーションを実行するために実際に必要になる可能性のあるものを切り取り始めることができることを理解する必要があります。 したがって、スクラッチのようなものにまで踏み込む場合は、アプリケーションが必要とするすべての基盤テクノロジーを理解する必要があります。 たとえば、スクラッチで作業を行うと、ネットワークライブラリがDNS over TCPのようなものをサポートしていないことに気付くかもしれません。また、Kubernetesクラスタでアプリケーションを実行するためにはそれが必要であることに気づくかもしれません。 これらは、ベースイメージを可能な限り最小限の状態にまで削り取ろうとするほど、考慮しなければならない種類のものです。

 

トラステッドベースイメージ (9:11)

さて、ベースイメージを削ぐことについて話しました。 アルパインをベースイメージとして選んだと仮定しましょう。 次の問題は、そのアルパインはどこから手に入れるのかということです。 誰がそれを作り、どのように作ったのかをどうやって知ることができますか? ですから、コミュニティの画像、例えばスーパーエリートのアルパインのようなものを使うこともできますが、誰が作ったのか、なぜ作ったのか、安全かどうかもわかりません。 より良いオプションは、ここの下部に示されているように、Docker公式イメージのようなものを使用することです。これは、Docker公式イメージであることを示すタグが付いたAlpineです。 つまり、Dockerが独自に構築したか、Dockerがコミュニティと直接連携して構築を監督したかのどちらかです。 だから、私たちはその中に何が含まれているかを正確に知っています。 Docker 検証済みの発行元イメージは、Red Hat、Suse、Grafana などのパートナーからのものであり、それらの出所を支えています。 そして、ハード化されたイメージがあります。 強化されたイメージとは、CVE が削除され、SLA が設定されたイメージです。 それも利用可能な別のオプションです。

 

Docker Scout (10:17)

さて、個々のイメージの保護から離れて、Docker Scoutと、信頼できるソフトウェアサプライチェーンを提供するためにこれに何が提供できるかについて話し始めましょう。 では、開発プロセスを見てみましょう。 ですから、開発者として、この場合は私がプロデューサーになります。 私は、アプリケーションを書いているときにベストプラクティスに従うように試みるつもりです。 私は自分のコード、ソースコードを持っていて、それを書くつもりです。 私は、引き込む予定のさまざまな依存関係を持つことになります。 アプリケーションが正しく動作するために必要なさまざまなライブラリやその他のものがあります。 Dockerfileを使用してそれらをビルドします。 その時点で、何らかの脆弱性スキャンが行われることになります。 作成されるパッケージやイメージがあります。 そして、それは消費者に届けられるのです。 このプロセスでは、ベストプラクティスに従ってみたいと思います。 私は、自分が書いているコードが安全であることを確認しようと思います。 取得している依存関係が、人気があり、安全であると思われる適切なものであることを確認しようと思います。 ビルドのベストプラクティスに従うように努めます。 だから、開発者としての私はかなり気分が良いです。 私は、これが送信される安全なコードであることを確認するために、常識的なことをしようとしました。 だから、自分の仕事はかなりうまくいったと感じています。

ですから、もし私がこのプロセスの消費者であり、このすべてが閉じた箱であり、何が起こったのかわからないとしたら、突然、あらゆる種類の疑問が湧いてきます。 誰がこれを作ったのですか? ソースコードが侵害または操作されていないことを確認するにはどうすればよいですか? または、依存関係があなたが言うとおりのものであることをどうやって知ることができますか? または、ビルドが改ざんまたは変更されていないこと、またはパッケージが侵害されたことをどのように確認できますか? それとも、これがすべて古くて、今ではそれに対する脆弱性がたくさんあるとしたらどうでしょうか? これらは、ソフトウェアの消費者が実際に何を得ているのかを本当に理解し、それが自分の環境にとって安全であることを確認したいと思っているために尋ねている重要な質問です。 そのため、これらの問題を定義し、解決するためのツールが必要です。

さて、これを行うために利用できるツールがいくつかあります。 1つ目は、ソフトウェア部品表(SBOM)です。 これにより、このソフトウェアアーティファクトに何が含まれているかがわかります。 つまり、その中にあるさまざまなパッケージがすべてわかります。 次は来歴です。 来歴とは、遺物の歴史、それがどこから来たのか、誰が作ったのか、どのように作ったのかを証明するものです。 そして最後に、パッケージの署名があります。 これは、出所とその信頼性を検証する認証であり、消費者は、自分が得ているものが実際にそうであり、ある種の代替品ではないことがわかります。

 

ソフトウェア部品表 (12:50)

さて、それでは、ソフトウェアの部品表についてもう少し詳しく説明しましょう。 そこで、食品の栄養と成分のリストがあります。 これはすべての食品に必要であり、非常に役立ちます。 カロリーやコレステロールなど、あらゆる情報を得ることができます。 また、降順で材料のリストも表示されます。 したがって、ここに何があるか、そして次のアイテムに対して各アイテムがどれだけあるかを確認できます。 また、一番下には、アレルギーを持つ人々にとって重要な特定のアレルゲンが含まれているかどうかについてのものがあります。 これにより、これらのCookieとその内容について多くの情報が得られます。 だから、そのクッキーを食べるかどうかについて、情報に基づいた決定を下すことができます。 では、ソフトウェアについても同じことができるとしたらどうでしょうか、しかし、実際にはこれよりも優れたことができるとしたらどうでしょうか。 ソフトウェア部品表を使用すると、パッケージとなる成分のリストを提供するだけでなく、実際にそれらのパッケージのそれぞれに関する情報、サプライヤーが誰であるか、バージョンが何であるか、それらの間の依存関係が何であるかを提供できます。 彼らの信頼性のためにこれの作者は誰ですか。 これらの情報はすべて、ソフトウェアの部品表に含めることができます。 つまり、Cookieレベルの情報を提供するだけでなく、それ以上の情報を提供し、ソフトウェアビルドマテリアルが関連付けられているこの特定のアーティファクトをどのように信頼するかについて、より適切な決定を下すことができます。

ソフトウェア部品表にはさまざまな形式があります。 ソフトウェアパッケージのデータ交換とサイクロンDXがあります。 Scout は、これらの異なる形式の両方をサポートしています。 また、Vulnerability Exploitability Exchange(脆弱性悪用可能性交換)またはVEXドキュメントと呼ばれるものもあり、オプションで追加することができます。 VEXのドキュメントが行っていることは、この特定のパッケージにこの特定の脆弱性があると言えるようにしていることですが、何らかの理由でコードのその部分を実際に実行していないため、この脆弱性を悪用することはできません。 そうすることで、確かにこの脆弱性はあるが、心配する必要はないのだと理解することができます。 つまり、脆弱性に関する懸念やそのようなことの騒々しさにかかっているのです。

 

Docker Scout (15:01)

Docker Scout では、さまざまな機能を提供しています。 Docker Hub内には、ベースイメージや使用できるその他のイメージをプルダウンするための信頼できるコンテンツがあります。 私たちは、ソースからビルドパッケージまで、SDLCを通じてポリシー評価を行っており、誰もが何が起こっているのかを確認できるようにし、このプロセス全体に関する記録システムを提供しています。 私たちは皆、このプロセスのどこに画像があるかに関係なく、画像で何が起こっているかを理解しています。 Scoutは、サプライチェーン全体にわたって実用的な洞察を提供します。 したがって、Docker Scoutを使用すると、ソフトウェアの品質を確保し、顧客から信頼され、実装しているガードレールまたはポリシーに準拠していることを確認できます。

では、スカウトは実際に何をしているのでしょうか? ここで詳しく説明しましょう。 まず、脆弱性情報のさまざまなソースをまとめることです。 さて、脆弱性について話すとき、彼らはしばしば国家脆弱性データベースについて話します。 これは、多くの人が脆弱性を取得するために行く場所です。 しかし、これらの他のデータベースや脆弱性のカタログの多くは、実際には脆弱性データベースよりも脆弱性について詳細に説明していることがわかりました。 私たちが行っているのは、これらすべての異なるソースを1時間に最大3回プルし、それらすべてを1つのデータベースにまとめることで、これらすべての異なるソースから最適な情報を入手し、ソフトウェアにどのような脆弱性があるかを実際に理解できるようにすることです。

さて、これの次の部分は、脆弱性をより早く見つけて修正することです。 私たちは、人々がCIプロセスやテストプロセス、または残念ながら本番環境で脆弱性を見つけているのを目の当たりにしています。 可能であれば、プロセスの早い段階で脆弱性を見つける方がはるかに良いでしょう。 そのため、開発者は、使用しているソフトウェアにどのような脆弱性があるかを理解し、それらを修正する方法に関する情報を入手できるようにしたいと考えています。 これは、開発者がこの情報を見ることができ、まったく異なるプロセスやまったく異なる見方ではなく、今日のソフトウェアとの自然な部分であるように、開発者がこの情報を見ることができるようにするために、私たちDockerにとって非常に重要です。 しかし、脆弱性についてだけ話しているわけではありません。 また、ポリシーについても話しています。 私たちは、ポリシーを設定し、開発者、CI、SDLC全体がそれらのポリシーを遵守できるようにしたいと考えています。 「修正できる重大な脆弱性はない」というようなこともあり、「基本イメージは最新の状態にあるか」や「使用したくない特定のGPLライセンスを使用しているか」、あるいは「実行すべきでないのにrootユーザーとして実行していないか」といったこともあります。 そのため、ポリシーは脆弱性を超えたさまざまなものに基づいている可能性があります。

したがって、次はCIプロセス自体を見ていきます。 したがって、CIプロセスがあり、開発者が行っていることとは異なる脆弱性の評価方法がある場合、脆弱性が何であるか、どのように評価され、どのように修正されているかを理解しようとするのに問題が発生する可能性があります。 Docker Scout を CI プロセスに直接統合する機能を提供しています。 このように、開発とCIの両方で同じ評価プロセスが進行するため、脆弱性とは何か、VEXステートメントなどがあるかどうかについて全員が同意します。

さて、次に脆弱性のステータスを評価したいと思います。 SDLC全体でそれが何であるかを理解する必要があります。 ですから、開発者が何をしているのか、さまざまなリポジトリに何がチェックインされているのかを見て、その情報を収集し、実際にScoutダッシュボードを通じて理解できるようにします。 そのため、すべての画像のすべてのメタデータをリアルタイムで確認し、ここで何が起こっているのかを実際に理解し、必要なアクションに優先順位を付けることができます。 SDLCと脆弱性についてここで注意すべき重要な部分は、常に脆弱性がゼロになるわけではないということです。 常に新しい脆弱性が侵入しているため、脆弱性で何が起こっているかをリアルタイムで把握することは、すべての異なる環境で重要になります。

また、本番環境で何が起こっているのかを理解できるようにしたいと考えています。 Docker Scoutを使用すると、本番環境にタグ付けされたイメージを実際に見て、本番環境で何が起こっているかを確認できます。 また、本番環境のランタイム分析を結び付けて、それで何が起こっているかを確認することもできます。 そのため、本番環境で実際に何が実行されているのかをより深く理解し、それに伴う脆弱性やポリシーの問題を確認することができます。 Docker Scoutは、Docker Desktopや開発用のコマンドライン、さまざまなCI/CDツール、Artifactory、ECR、ACRなどのレジストリ、Sysdigなどのランタイムツールなど、さまざまなツールと統合されており、時間の経過とともにこれらの統合に常に新しい機能が追加されています。

 

デモ (16.18)

それでは、私が話してきたこれらの機能の一部を示す時が来ました。 そこで、Scoutのデモサービスを使用します。 URLはこちらでご覧いただけます。 同じGitHubリポジトリをダウンロードして、そのGitHubリポジトリを使用して自分で行おうとしているのと同じデモを行うことができます。 次に、VS codeに切り替えます。 ここにはScoutのデモサービスがあり、この特定のイメージを構築することから始めます。 そして今、この特定のイメージを構築します。 これには約 20 秒かかります。 そして、このイメージを構築したら、Scoutが何を提供できるかを検討し始めます。 さて、この特定のイメージを構築しました。 ここですぐにヒントがあることに気付くでしょう:ねえ、イメージの脆弱性の推奨事項を見たい、このDocker Scoutクイックビューを実行してください。 私はそうしたいです。 だから、それをコピーしてそこに貼り付けます。

さて、ここで何が起こったのか見てみましょう。 そのためのソフトウェア部品表を作成しました。 このソフトウェア部品表は前の例からキャッシュされましたが、ソフトウェア部品表の材料が生成されます。 次に、この特定のイメージに対するポリシーを評価します。 そして、ここから、脆弱性に関する情報を提供します。 うわー、高値 20 、中 8 、 4 安値の2つのクリティカルがあるようです。 私は本当に、これらのクリティカルとハイの世話をしたいです、私はできるなら。 そして、ポリシーに下がると、ポリシーのステータスが失敗であることが表示されます。 そのため、修正可能な重大で高い脆弱性だけでなく、対処する必要がありますが、Dockerfileにデフォルトの非rootユーザーがいません。 そのため、それを修正する必要があり、開発者としては修正できないサプライチェーンアウトの認証が欠落していますが、それが何で起こっているのかを理解することが重要です。

だから、ここから、私はいくつかのことを行うことができます。 繰り返しになりますが、それは私に何ができるかについてのヒントを与えてくれます。 私は自分のポリシー違反を見に行くことができます。 自分の弱さを見つめることができます。 私は先に進んでそれをします。 だから、私は先に進んで、ここでそれを行うつもりです。 CVEのリストをパッケージごとに取得します。 ですから、ここに来て、各パッケージにCVEが含まれていることを実際に確認することができます。 そして、CVEごとに、CVE番号を取得します。 その特定のCVEの詳細を実際に確認するためのURLを取得します。 影響を受ける範囲と固定範囲を取得します。 私は実際にこれらのそれぞれを修正するために何を変更する必要があるかを知っています。 これは、私が探しているすべての情報を与えてくれます。 ScoutのデモでDocker Scout SBOMを実行することもできます。 そして、これにより、SBOMの読みやすい形式が得られます。 これにより、そのソフトウェアの部品表がどのようなものかがわかります。 ここでは、パッケージの種類、名前、バージョン、パッケージの作成者、パッケージの説明、ライセンス、アクセス先のURL、そして実際にこの特定の部分に到達するためのパスを確認できます。 これは、ソフトウェアビルドマテリアル内に表示される情報の種類であり、これらのパッケージがそこに含めたいものであり、含めることに抵抗がないと感じるものかどうかを理解するのに役立ちます。

これまでに示したすべてのものはコマンドラインを介しており、このすべての作業はコマンドラインから実行でき、示した方法を使用するだけで実行できます。 しかし、GUIも示し、それで何ができるかを示します。 ここでは、Docker Desktop GUIを使用しています。 実際には、Scoutのデモ画像にアクセスして、パッケージやCVEを表示するか、単にクリックするだけで同じものが表示され、前に見たのと同じ脆弱性情報が表示されますが、レイヤーごとの形式で表示されます。 ベースイメージにはたくさんの脆弱性があることがわかりますが、ここに来ると、ちょっと待ってください、ビルドの一部として導入した脆弱性がいくつかあり、それを処理する必要があることがわかります。 ですから、私はこれらを見て、これらに何が起こっているのかを見ようとすることができます。 ですから、この特定のアプリケーションでのエクスプレスを知っているからといって、エクスプレスに行くと、ここには複数の脆弱性があることがわかります。 だから、最初のものに行くと、説明が出て、「これは 4で修正されました」と教えてくれます。17。3。 OK、だから私は少なくとも 4に更新する必要があります。17。3。 次のものに行って、何が書いてあるか見てみましょう。 これは 4と言っています。19。2。 よし、じゃあやってみよう。 そして、ここにはもう一つあります。 そして、これは 4と言っています。20。0。 さて、これはただの低さでしたが、私はその 4を知っています。20。0 は私にとってより良いバージョンです。 だから私は先に進んで、それを 4に更新するつもりです。20。0。 では、今すぐにでも始めましょう。 VS Code に戻ります。 ここでパッケージリストを開きます。 そして、私は降りてきて、これが私のエクスプレスです。 だから私は先に進んで、それを 4に変更します。20。0。 そして、私たちはそれを保存するつもりです。 そして今、私はこれを2 Vを構築します。 これで、新しいパッケージでビルドされます。 繰り返しになりますが、ビルドには数秒かかります。 そして、クイックビューを再実行して、何が起こっているのかを確認します。 ここでクイックビューを実行すると、脆弱性の数が減少していることがわかりますが、これは良いことです。 それが私たちが望んでいることであり、脆弱性の数が実際に減少していることを確認したいのです。 今、私はまだベースイメージにたくさんのものを持っています。 そこで、もう一度、GUIに戻るのは、これをグラフィカルに表示する優れた方法を提供するからです。 私はV2 に入り、今度は推奨される修正を見るつもりです。 CLIでこれを再度行うことも、ここで行うこともできます。 ベースイメージの推奨事項を取得します。 それは、大丈夫、1つのオプションは、単にベースイメージを更新して最新のものを引き出すことができるということです。 しかし、それは私が本当にやりたいことではありません。 ベースイメージを指定したいです。 だから、私はここに来るつもりです。 私は現在 3を使用しています。14。 そして今、それは言っています、OK、あなたは 3に行くことができます。20。 そして、それは実際にあなたのクリティカルを 2、あなたの高値を 15減らすことになります。 あなたはまだ 1 媒体を持っているでしょう。 私はそれで大丈夫です。 この新しいパッケージについて少し情報を提供しています。 そして、これは from コマンドです。 だから、私はそれをつかむつもりです。 VSコードに戻ります。 Dockerfileに移動します。 ここに私のfromステートメントがあります。 そして、新しいものを入れて保存します。 そして、これをもう一度作りましょう。

だから今、私たちはV3を構築します。 ああ、それをする前に、そのユーザーを修正する必要があることをほとんど忘れていました。 だから私はこれをrootとして実行していません。 では、それもやってみましょう。 そして今、私たちは v3を構築します。 新しいベースイメージを引っ張るだけです。 そのため、再びビルドされるまでに数秒かかります。 大丈夫です。 それでは、もう1つクイックビューを見てみましょう。 先に進んで、これを上に動かして見ることができるようにします。 これで、root以外のユーザーが解決されたことがわかります。 修正可能なクリティカルまたはハイは解決されていません。 そして、ここを上にスクロールすると、中低域と21低域が残っていることがわかりますが、これは問題ありません。これは、個々の開発者が脆弱性とポリシーの問題を理解し、ガイダンスを使用してそれらを修正できる、開発者の視点の例を示しています。 それでは、スカウトダッシュボード(scout.docker.com)を見て、より高いレベルで何が起こっているのかを実際に確認できるようにしましょう。

もし私がここに来て、ブラウザに行って scout.docker.com に行くと、 リンクしたリポジトリからインデックスが作成されたすべてのイメージのダッシュボードが表示されます。 Docker Hub、Artifactory、ECR、ACRのいずれであっても、それらに関する情報を見ることができること。 ここでは、ポリシー、デフォルトの非rootユーザー、AGPL V3 ライセンスなし、修正不可能な重大な脆弱性または高い脆弱性を確認できます。 コンプライアンスに関する情報は見ていますが、過去7日間の傾向も見ています。状況は良くなったのか、それとも悪くなったのか。 何が起こっているのかをよりよく理解できます。 SonarQubeの品質ゲートのようなものも見ることができます。 また、常に新しい脆弱性が発見されているため、脆弱性が何であるかをリアルタイムで確認することもできます。 そのため、新たな脆弱性が発見された場合は、すぐに知りたいものです。 すべてのものを完全に再スキャンする必要はありません。 あなたはリアルタイムで知りたいです-私はそれによってどのように影響を受けますか? 次のLog4jが出てきたら、コードに何週間も費やす必要はありません。 このバージョンのLog が j のどのアプリケーションにあり、どのように修正するのかをすぐに知りたいですか4Scoutでは、これらの重大で重大な脆弱性や任意の脆弱性を実際に確認し、さまざまなイメージのどれが影響を受けるかをすぐに確認できる機能を提供しています。 これは、ソフトウェア請求書の資料を使用して、どのパッケージがどのイメージに含まれているか、そしてそれらの影響が何であるかを理解するためにできることです。 したがって、ここでは、最近のさまざまな高および重大な脆弱性の一部を確認し、影響を受けるイメージを確認できます。 だから、すぐにその中に入って、特定のものを見ることができます。

ここからは、最後にプッシュされたものを示していますが、タグ付けを使用して環境を指定すると、本番環境としてタグ付けされた環境を実際に見ることができ、本番環境でどのように機能しているかを確認することもできます。 これにより、本番環境と他の本番環境がどうなっているかを実際に確認することができます。 今では、概要だけでなく、個々のポリシーなどを見て、週ごとにどのように進んでいるかを確認できます。 個々のイメージ、インデックス化されたすべての異なるイメージ、脆弱性の数、最後にプッシュされたのはいつか、そのようなもの、ポリシーに準拠しているかどうか、すべての情報を調べることができます。 ベースイメージを見て、さまざまなイメージでどのベースイメージが使用されているかを確認し、それに関する情報を取得できます。 個々のパッケージを見て、どの特定のパッケージがどの特定の画像で使用されているかを確認できます。 私たちは脆弱性によって行くことができます。 したがって、CVE番号がある場合は、ここにドロップして、その影響を受けるすべての特定の画像を確認できます。 また、臨界度で並べ替えることもできます。 したがって、ここではCVSスコア 10 脆弱性を示し、それらが含まれている画像は次のとおりです。 また、ここではさまざまなタイプのシステムへの統合についても見ていきます。 コンテナレジストリへの統合、CI統合、リアルタイム更新、統合など、これらすべてを確認できます。 ここでも、すべての異なる統合に関する情報を取得できます。

さて、このプレゼンテーションをお聞きいただき、誠にありがとうございました。 Scoutでの作業を楽しみ、新しいコンテナを保護できることを願っています。 ありがとうございます。

 

さらに詳しく

コンテナは、多くの場合、本番環境などの安全な環境で実行されます。 安全なコンテナを作成するには何が必要ですか? イメージの構築方法とコンテナとしての実行方法の両方が、コンテナのセキュリティに影響します。 コンテナセキュリティとDocker Scoutのセッションでは、コンテナユーザー、読み取り専用コンテナ、Linux権限、イメージに含めるべきもの、基本イメージ、脆弱性、ポリシーの適用、修復など、セキュリティの複数の側面について説明します。

登壇者

Kevin Barfield氏、ディレクター、ソリューションアーキテクト、Docker