Docker のセキュリティ機能には、1. 暗号化されたノード ID、2. TLS ベースの認証メカニズム、3. セキュリティ アクセス トークン、4. 定期的な証明書の自動更新をサポートする CA 構成、5. 暗号化されたクラスター ストレージ、6.暗号化されたネットワーク、7. Docker セキュリティ スキャン、8. Docker コンテンツの信頼、9. Docker キーなど。
このチュートリアルの動作環境: linux5.9.8 システム、docker-1.13.1 バージョン、Dell G3 コンピューター。
Docker プラットフォームには、独自のセキュリティ テクノロジも多数導入されています。 Swarm モードは TLS に基づいて構築されており、非常にシンプルかつ柔軟に設定できます。セキュリティ スキャンは、バイナリ ソース コード レベルでイメージをスキャンし、既知の欠陥の詳細なレポートを提供します。
Docker コンテンツの信頼により、ユーザーはコンテンツに署名して認証できるようになり、キーは Docker の第一級市民になりました。 Docker はこれらのセキュリティ テクノロジに適切なデフォルト値を設定しますが、ユーザーは構成を変更したり、これらのセキュリティ テクノロジを無効にしたりすることもできます。
Swarm モード
Swarm モードは、Docker の将来のトレンドです。 Swarm モードを使用すると、ユーザーはクラスター内の複数の Docker ホストを管理し、宣言的な方法でアプリケーションをデプロイできます。
各 Swarm はマネージャー ノードとワーカー ノードで構成され、ノードは Linux または Windows にすることができます。マネージャー ノードはクラスター内の制御層を形成し、クラスターの構成とワークロードの分散を担当します。ワーカー ノードは、アプリケーション コードを実行するコンテナです。
予想通り、Swarm モードにはすぐに使える多くのセキュリティ機能が含まれており、適切なデフォルトも設定されています。これらのセキュリティ機能には次のものが含まれます。
暗号化されたノード ID。
TLS ベースの認証メカニズム。
安全なアクセス トークン。
証明書の定期的な自動更新をサポートする CA 構成。
暗号化されたクラスター ストレージ (構成 DB)。
Docker セキュリティ スキャン
コードの欠陥を迅速に発見する機能は非常に重要です。 Docker Security Scanning を使用すると、Docker イメージ内の既知の欠陥を簡単に検出できます。 Docker セキュリティ スキャンが、Docker Hub のプライベート リポジトリ イメージで利用できるようになりました。同時に、このテクノロジーは、Docker の信頼できるサービスのローカリゼーション展開ソリューションの一部としても使用できます。最後に、すべての公式 Docker イメージはセキュリティ スキャンされており、スキャン レポートはリポジトリで利用できます。 Docker セキュリティ スキャンは、バイナリ コード レベルで Docker イメージをスキャンし、既知の脆弱性のデータベース (CVE データベース) と照合してそのソフトウェアをチェックします。スキャンが完了すると、詳細なレポートが生成されます。 ブラウザを開いて Docker Hub にアクセスし、Alpine リポジトリを検索します。下の画像は、公式 Alpine リポジトリの [タグ] タブを示しています。 #Alpine 倉庫は公式の倉庫です。つまり、倉庫は自動的にスキャンし、対応するレポートを生成します。ご覧のとおり、edge、lates、および 3.6 のイメージ タグが付いたイメージはすべて、既知の欠陥のチェックに合格しています。ただし、alpine:3.5 イメージには既知の欠陥があります (赤色でマーク)。 alpine:3.5 イメージを開くと、以下に示す詳細情報が表示されます。 これは、独自のソフトウェアの既知の欠陥の詳細を発見する簡単な方法です。 Docker Trusted Registry (DTR) は、Docker Enterprise Edition のローカライズされたイメージ ウェアハウス サービスの一部です。同じ機能を提供し、ユーザーがイメージ スキャンのタイミングとスキャン方法を制御できるようにします。 たとえば、DTR を使用すると、画像がプッシュされたときにスキャンを自動的にトリガーするか、手動でのみトリガーできるかを選択できます。同時に、DTR を使用すると、ユーザーが CVE データベースを手動で更新することもできます。これは、DTL がインターネットに接続して CVE データを自動的に更新できないシナリオにとって理想的なソリューションです。 これは Docker セキュリティ スキャンであり、Docker イメージに既知のセキュリティ上の欠陥があるかどうかを詳細に検出する優れた方法です。もちろん、能力が高ければ高いほど責任も大きくなり、ユーザーが不具合を発見した場合には、対応する不具合を解決する責任を負わなければなりません。Docker Content Trust
Dockr Content Trust (Docker Content Trust、DCT) を使用すると、ユーザーはダウンロードしたイメージとその整合性を簡単に確認できます。その発行者。これは、信頼できないネットワーク環境でイメージをダウンロードする場合に重要です。 大まかに言えば、DCT を使用すると、開発者は Docker Hub または Docker Trusted Services に公開されたイメージに署名できます。これらのイメージがプルされると、署名ステータスが自動的に確認されます。以下の画像は、このプロセスを示しています。 #DCT は、イメージが署名されているかどうか、本番環境で使用できるかどうか、イメージが新しいバージョンに置き換えられているかどうかなど、重要なコンテキストも提供できます。時代遅れになるなど。DTC が提供するコンテキストはまだ初期段階にあり、構成は非常に複雑です。 Docker ホストで DCT 機能を有効にするには、環境内で DOCKER_CONTENT_TRUST 変数を 1 に設定するだけです。
$ export DOCKER_CONTENT_TRUST=1
実際の環境では、ユーザーはシステムのデフォルトでこの機能を有効にすることができます。
Docker 統合構成レイヤー (Docker Enterprise Edition の一部) を使用する場合は、次の図に示すように、「署名付きイメージのみを実行」チェックボックスをオンにする必要があります。これにより、UCP クラスター内のすべてのノードが署名付きイメージのみを実行するようになります。
上の図からわかるように、UCP はさらに DCT をカプセル化し、署名されたイメージのセキュリティ設定情報を提供します。たとえば、ユーザーは、実稼働環境では secops によって署名されたイメージのみを使用できるという要件を持つ場合があります。
DCT 機能をオンにすると、署名のない画像を取得して使用することはできなくなります。次の図は、DCT がオンになった後、Docker CLI または UCP Web UI インターフェイスを介して署名されていないイメージを再度プルしようとしたときに報告されるエラーを示しています (どちらの例も、ラベル「unsigned」が付いたイメージをプルしようとしています)。
次の図は、DCT が Docker クライアントによる改ざんされたイメージのプルをどのように防ぐかを示しています。
#次の図は、DCT がクライアントによる古いイメージのプルをどのように防ぐかを示しています。
Docker コンテンツ トラストは、ユーザーが Docker サービスから取得したイメージを確認するのに役立つ重要なテクノロジーです。このテクノロジーの基本モードの設定は非常に簡単ですが、コンテキストなどの一部の高度な機能の設定は、この段階ではまだ非常に複雑です。
Docker キー
多くのアプリケーションにはキーが必要です。パスワード、TLS 証明書、SSH キーなど。
Docker バージョン 1.13 より前には、アプリケーション間でキーを共有する標準的で安全な方法はありませんでした。一般的な方法は、開発者がキーをテキストとして環境変数に書き込むことです。これは理想からは程遠いです。
Docker1.13 では Docker キーが導入され、キーが Docker エコシステムの第一級市民に変わります。たとえば、キーを管理するために新しいサブコマンド docker secret が追加されました。 Docker の UCP インターフェイスには、キーを作成および管理するための専用の場所もあります。
キーは作成後および送信中にバックグラウンドで暗号化され、使用時にメモリ ファイル システムにマウントされ、許可されたサービスのみがアクセスできます。これはまさに包括的なエンドツーエンドのソリューションです。
下の図は、プロセス全体を示しています。
上図に示すワークフローの各ステップを順番に紹介します。
1) キーが作成され、Swarm に送信されます。
2) キーはクラスター ストレージに保存され、暗号化されます (各マネージャー ノードはクラスター ストレージにアクセスできます)。
3) サービス B が作成され、キーが使用されます。
4) サービスBのタスクノード(コンテナ)への鍵送信処理は暗号化されています。
5) サービス B のコンテナーはキーを復号化し、それをパス /run/secrets にマウントします。これは一時的なメモリ内ファイル システムです (Windows にはメモリ内ファイル システムの概念がないため、Windows Docker ではこの手順が異なります)。
6) コンテナ (サービス タスク) が完了すると、メモリ ファイル システムが閉じられ、キーが削除されます。
7) サービス A のコンテナーはキーにアクセスできません。
ユーザーは docker Secret サブコマンドを使用してキーを管理でき、docker service create コマンドの実行時に --secret を追加することでサービスのキーを指定できます。
推奨される学習: 「docker ビデオ チュートリアル 」
以上がdocker のセキュリティ機能は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。