リモートのアルバイトで始めた仕事が、長期化、長時間化。
Slackでの開発者との仕事で、文字が小さくスレッドやチャンネル迷子は相変わらず日常茶飯事。
Slackの中で、最初に覚えたマークダウンはまた、コードをインライン表示すること
` バッククォート`
最近、Qiitaでのありがたい編集のフィードバックで覚えた
コードブロックの書き方
(空行)
```
code....
```
(空行)
コーディングとは程遠いですが、新しいトリックを覚えるのはシンプルに楽しいなと思えた瞬間でした。
さて、今回はこちらの翻訳のご紹介です。
こちらに関連し以前ご紹介した
安全なNode.jsのためのDockerイメージ構築のステップバイステップのチュートリアルの翻訳も、ぜひ参照してみてください。
では、今回のお題をご案内しますね。
Docker for Node.jsデベロッパ：セキュリティを失敗させないために知っておくべき5つのこと
Liran Talリランタル
2021年1月25日
Dockerは、コンテナイメージのダウンロード数が合計で500億を超えています。Docker Hubでは何百万ものアプリケーションが利用できるため、コンテナベースのアプリケーションは人気があり、アプリケーションを簡単に使用および公開が可能です。
Docker Node.js のWebアプリケーションを構築する単純な方法(qiita翻訳）には、多くのセキュリティリスクが伴う可能性があります。では、Node.jsデベロッパにとってセキュリティをDockerで考慮するにはどうすればよいでしょうか。
Docker for Node.jsとDockerイメージの構築の要点に飛び込む前に、このトピックに関するよくある質問を見てみましょう。
Node.jsアプリケーションをdockerizeするにはどうすればよいですか？
DockerコンテナでNode.jsアプリケーションを実行するには、プロジェクトのディレクトリをコピーして、必要なnpmパッケージをすべてインストールするだけでよいのですが、セキュリティや生産に関する多くの懸念事項を見逃す可能性があります。 Dockerを使用したNode.jsWebアプリケーションのコンテナ化では、正しいDockerベースイメージの選択から、多段ビルドの使用、シークレットの安全な管理、本番関連のフレームワーク設定の適切な有効化まで、すべてをカバーしています。
この記事では、Webアプリケーションに適切なNode.js Dockerベースイメージを選択することの影響をよりよく理解するために必要な情報に焦点を当て、アプリケーションで利用できる最も安全なDockerイメージを見つけるためのガイドを提供します。
DockerはNode.jsデベロッパにとってどのように役立ちますか？
Node.jsアプリケーションをコンテナーにパッケージ化すると、ランタイム、構成、OSレベルの依存関係、およびWebアプリケーションがさまざまなプラットフォームやCPUアーキテクチャーで実行するために必要なすべてのものを含む完全なアプリケーションをバンドルできます。これらのイメージは、コンテナーイメージと呼ばれるデプロイ可能なアーティファクトとしてバンドルされています。これらのDockerイメージは、簡単に再現可能なビルドを可能にするソフトウェアベースのバンドルであり、Node.jsデベロッパにすべての環境で同じプロジェクトまたは製品を実行する方法を提供します。
最後に、Dockerコンテナを使用すると、デベロッパは、特別な権限を必要とせずに、またはプロジェクトを実行するための専用環境をセットアップすることなく、新しいプラットフォームリリースやその他の変更をより簡単に試すことができます。
- アプリケーションに適したNode.jsのDockerベースイメージを選択する Node.jsのプロジェクトでDockerイメージを作成する場合、Docker Hubから引っ張ってきた別のDockerイメージをベースに、独自のアプリケーションイメージを構築します。これはベースイメージと呼ばれるものです。ベースイメージは、これから構築するNode.jsアプリケーション用の新しいDockerイメージの構成要素になります。 ベースイメージの選択は、Dockerイメージのビルド速度から、Webアプリケーションのセキュリティやパフォーマンスまで、すべてに大きく影響するため、非常に重要です。DebianやUbuntuをベースとした本格的なオペレーティングシステムイメージを選択するのは、このイメージで利用可能なすべてのツールやライブラリを活用することができるでしょう。
しかし、これには代償があります。ベースとなるイメージにセキュリティ上の脆弱性があると、新しく作成するイメージもそれを引き継ぐことになります。なぜ、多くの脆弱性を含む大きなベースイメージをデフォルトにした悪条件でスタートしたいのでしょうか？
ベースイメージを見ると、セキュリティ脆弱性の多くは、このベースイメージが使用しているOS（Operating System）層に属しています。Snykの2019年の研究「Shifting Docker security left」では、OS層がもたらす脆弱性は、選択する種類によって大きく異なることが示されました。
ちなみにこれは、利用を検討するすべてのベースイメージに対して、当てはまる懸念事項です。例えば、2020年の「オープンソースセキュリティの現状」レポートから、最新のイメージビルドを持つ上位のDockerイメージを紹介すると、Dockerのベースイメージには一貫してデフォルトでセキュリティの脆弱性が含まれていることがわかります。
2. 開発中にNode.jsのDockerイメージをスキャンする
他のイメージを基にDockerイメージを作成したり、それらを再構築することは、新たな脆弱性をもたらす可能性がありますが、あなたがその上に立つための方法があります。
Dockerイメージのビルドプロセスを、他の開発関連の活動と同じように扱います。あなたが書いたコードをテストするのと同じように、あなたがビルドしたDockerイメージもテストすべきです。
これらのテストには、Dockerfileにセキュリティ上の落とし穴やその他の悪いパターンがないことを確認するための静的ファイルチェック（別名linters）が含まれます。Dockerイメージのセキュリティのベストプラクティスで、これらの概要を説明しました。もしあなたがNode.jsアプリケーションのでエロっぱならなら、このステップバイステップの「DockerでNode.jsウェブアプリケーションをコンテナ化する10のベストプラクティス」を読みたいと思うでしょう。
git リポジトリを Snyk に接続することも優れた選択です。SnykはGitHub、GitLab、Bitbucket、Azure Reposとのネイティブな統合をサポートしています。gitとの統合を行うことで、プルリクエストをスキャンし、セキュリティの脆弱性を発見した場合には、セキュリティ情報を注釈として付与することが可能になります。これにより、プルリクエストが新たなセキュリティ上の脆弱性をもたらす場合、ゲートを設け、マージを拒否することができます。
継続的インテグレーション (CI) に柔軟性が必要な場合、または密接に統合された開発者エクスペリエンスが必要な場合は、Snyk CLI をご利用ください。
CLIを使用すると、Dockerコンテナ・イメージを簡単にテストすることができます。例えば、ローカルでDockerイメージを構築して、タグ付けしているとします。
nodejs:notification-v99.9—次のようにテストします:
Snyk CLIをインストール:
$ npm install -g snyk
Snyk CLI が自動でAPIトークンを自動的に取得:
$ snyk auth
ローカルのベース画像をスキャン:
$ snyk container test nodejs:notification-v99.9
テスト結果は、脆弱性を導入したパスであるCVEに関する情報とともに画面に出力されるので、どのOSの依存関係が原因なのかを知ることができます。
以下は、node:15のDockerのベースイメージをテストするための出力例です。 :
✗ High severity vulnerability found in binutils
Description: Out-of-Bounds
Info: https://snyk.io/vuln/SNYK-DEBIAN9-BINUTILS-404153
Introduced through: dpkg/dpkg-dev@1.18.25, libtool@2.4.6-2
From: dpkg/dpkg-dev@1.18.25 > binutils@2.28-5
From: libtool@2.4.6-2 > gcc-defaults/gcc@4:6.3.0-4 > gcc-6@6.3.0-18+deb9u1 > binutils@2.28-5
Introduced by your base image (node:15)
✗ High severity vulnerability found in binutils
Description: Integer Overflow or Wraparound
Info: https://snyk.io/vuln/SNYK-DEBIAN9-BINUTILS-404253
Introduced through: dpkg/dpkg-dev@1.18.25, libtool@2.4.6-2
From: dpkg/dpkg-dev@1.18.25 > binutils@2.28-5
From: libtool@2.4.6-2 > gcc-defaults/gcc@4:6.3.0-4 > gcc-6@6.3.0-18+deb9u1 > binutils@2.28-5
Introduced by your base image (node:15)
Organization: snyk-demo-567
Package manager: deb
Target file: Dockerfile
Project name: docker-image|node
Docker image: node:15
Platform: linux/amd64
Base image: node:15
Licenses: enabled
Tested 412 dependencies for known issues, found 554 issues.
Base Image Vulnerabilities Severity
node:15 554 56 high, 63 medium, 435 low
Recommendations for base image upgrade:
Alternative image types
Base Image Vulnerabilities Severity
node:current-buster-slim 53 10 high, 4 medium, 39 low
node:15.5-slim 72 18 high, 7 medium, 47 low
node:current-buster 304 33 high, 43 medium, 228 low
We have a Snyk CLI Cheatsheet, showing some of the magic you can do with it, and you can also find more information on how to get started with the Snyk Container CLI in our documentation.
Snyk CLI Cheatsheetでは、Snyk CLIでできる便利な機能の一部を紹介しています。また、Snyk Container CLIを使い始める方法についての詳細な情報は、当社のドキュメントでご覧いただけます。
3. Dockerイメージに含まれるNode.jsのランタイムの脆弱性を修正する
Dockerコンテナ・イメージのリスクを管理する際に見落としがちなのが、アプリケーション・ランタイムそのものです。Java用のDockerを実践している場合でも、Node.jsウェブアプリケーション用のDockerを実行している場合でも、Node.jsアプリケーションランタイムそのものが脆弱である可能性があります。
Node.jsのセキュリティリリースとNode.jsのセキュリティポリシーに注意し、従う必要があります。手動でこれらをフォローする代わりに、Snyk を活用して Node.js のセキュリティ脆弱性を見つけることもできます。
Node.jsのさまざまなベース画像タグのセキュリティ脆弱性について、より多くのコンテキストを提供するために、Snyk CLIでそれらのいくつかをスキャンし、次の対数スケールチャートに結果をプロットしてみました:
このようなことがわかりました:
1. node:latestとも呼ばれるデフォルトの node base imageタグは、500以上のセキュリティ脆弱性をバンドルしていますが、Node.jsランタイム自体にも2つのセキュリティ脆弱性を導入しています。現在、Node.js 15バージョンを実運用しており、パッチや修正を行っていない場合は、これは懸念事項となります。
2. node:alpine base image タグは、ベースイメージに脆弱な OS の依存関係をバンドルしていないかもしれません-これが青いバーがない理由です-が、最新の Node.js ランタイム（version 15）の脆弱なバージョンを含んでいることになります。
3. サポートされていないバージョンのNode.js（例えば、Node.js 10）を使用している場合、それは脆弱であり、セキュリティアップデートを受け取っていないことがわかります。
この記事を書いている時点で、リリースされている最新版であるNode.js version 15を選択した場合、実際にはこのコンテナ内の561のセキュリティ脆弱性だけでなく、Node.jsランタイム自体の2つのセキュリティ脆弱性にも晒されることになります。
このパブリック・イメージのテストURLでDockerスキャンのテスト結果を見ることができます。あなたが使用している他のNode.jsベースイメージタグを、この無料で公開されているDockerスキャンサービスでテストすることをオススメします。
SnykはDocker HubとDocker Desktopにおけるコンテナスキャンをサポートしており、セキュリティは今やDockerのワークフローに不可欠な要素となっています。また、SnykはDockerの公式イメージの公式セキュリティプロバイダでもあります。実際、Dockerを開発プラットフォームとして使用している方は、Docker Desktop with Snykと新しいDocker脆弱性チートシートをご参照ください。
すでにDockerのユーザーアカウントをお持ちの場合は、それを使ってSnykに接続し、Docker Hubリポジトリをすぐにインポートすることができます。
4. Node.jsアプリケーションにデプロイされたDockerイメージの監視
Dockerイメージを構築したあと、おそらくイメージを追跡するDockerレジストリにプッシュし、機能的なコンテナアプリケーションとしてデプロイし、起動できるようにしますよね。
なぜDockerのベースイメージを監視する必要があるのか？
ベース画像のスキャンと修正で、これまで説明したセキュリティガイドラインをすべて実践しているのであれば、それは素晴らしいことです。しかし、新しいセキュリティの脆弱性は常に発見されていることを心に留めておいてください。今、イメージに78件のセキュリティ脆弱性があったとしても、明日の朝、新しいCVEが報告され、運用中のコンテナに100件の影響がないとは限りません。そのため、コンテナイメージのレジストリ（コンテナのデプロイに使用しているイメージ）を監視することは、セキュリティ問題をすぐに発見し、修正できるようにするために非常に重要です。
もしあなたが有料のDocker Hubレジストリをイメージに使用しているなら、Docker HubにSnykによるDockerセキュリティスキャンが統合されているのを既にご存知かもしれません。
また、Snykアプリから多くのDockerイメージレジストリと直接統合することができます。例えば、Docker Hub、ACR、ECR、GCR、Artifactoryからイメージをインポートすると、Snykがこれらを定期的にスキャンし、見つかったセキュリティ問題についてSlackや電子メールで警告をうけることができます。
5. セキュリティガイドラインとプロダクショングレードの推奨に従って、安全で最適なNode.jsのDockerイメージを作成します。
これまでセキュリティガイドラインについてここまで読みすすめていただき、ありがとうございました！
あなたはJavaのデベロッパですか？こちらもぜひ、参照してください。
Javaデベロッパが知るべきDockerセキュリティ５つの大切なこと
10 best practices to containerize Node.js web applications with Docker
Dockerでnode.jsウェブアプリケーションをコンテナ化するための10のベストプラクティス - もしあなたがNode.jsデベロッパなら、Node.jsアプリケーション用に安全でパフォーマンスの高いDockerベースイメージを構築する方法を示すこのステップバイステップのチュートリアルは、とても気に入るでしょう。
SnykとDocker IDを使用して、コンテナイメージのテストと修正を開始するにはこちらへ
最後まで読んでいただき、ありがとうございました！！！
Contents provided by:
Jesse Casman, Fumiko Doi, Content Strategists for Snyk, Japan, and Randell Degges, Community Manager for Snyk Global