【図解】Docker・Kubernetesセキュリティ完全攻略！コンテナ環境のセキュリティリスクと実践的対策

現代のシステム開発において、DockerやKubernetesなどのコンテナ技術は、開発の現場で広く使われる技術になりました。デジタルトランスフォーメーション（DX）の推進とともに、アジャイル開発やDevOpsの実践が進み、その中核にコンテナ技術が位置付けられています。

しかし、利便性の裏側には新たなセキュリティリスクが存在します。従来のオンプレミス環境や仮想マシン（VM）とは異なるコンテナ特有のアーキテクチャは、攻撃者にとって新たな標的となります。「コンテナは隔離されているから安全」という誤解が、重大なセキュリティインシデントを招く原因となっています。

情報処理安全確保支援士試験の学習においても、クラウドセキュリティの一環として、コンテナやオーケストレーションツールのセキュリティを理解しておくことの重要性が高まっています。物理層からアプリケーション層までを一貫して防御する従来の考え方に加えて、コンテナイメージの管理やランタイム保護といった新しい視点が求められます。

本記事では、Docker単体のセキュリティから、Kubernetes（K8s）クラスターのセキュリティまで、試験合格に必要な知識を網羅的かつ実践的に解説します。技術の表面的な暗記ではなく、アーキテクチャからリスクを理解し、適切な対策を導き出せる思考力を養います。

コンテナ技術の基本構造とセキュリティ特性

コンテナセキュリティを理解するには、その構造的特性を深く理解する必要があります。仮想マシンと比較することで、セキュリティ上の境界線がどこにあるかを明確にしましょう。

仮想マシンとコンテナの決定的な違い

従来の仮想マシン（VM）は、ハードウェア上またはホストOS上で動作するハイパーバイザーという仮想化ソフトウェアを介して、ゲストOSごと環境を構築します。各VMは完全に独立したカーネル（OSの中核部分）を持って動作するため、高い隔離性が実現されています。

一方、コンテナ（Dockerなど）は、ホストOSのカーネルを複数のコンテナで共有します。コンテナエンジン（Docker Engineなど）が、Linuxの「Namespace（名前空間）」と「Cgroups（コントロールグループ）」を利用して、プロセスやリソースを論理的に隔離しているのです。カーネルという境界を共有する分、コンテナの隔離性はVMより低いと考えておく必要があります。

この「カーネル共有」という特性が、コンテナセキュリティ最大の要点です。コンテナ内のプロセスがカーネルの脆弱性を悪用した場合、コンテナの壁を突破し、ホストOSそのものや同じホスト上で稼働する他のコンテナを乗っ取るおそれがあります。これを「コンテナブレイクアウト（Container Breakout）」と呼びます。

ブレイクアウトの原因はカーネルの脆弱性だけではありません。コンテナランタイム（runc）の脆弱性（CVE-2019-5736、CVE-2024-21626など）や、特権モードでの起動、Dockerソケット（/var/run/docker.sock）のマウント、Kubernetesの hostPath によるホストのディレクトリのマウントといった設定不備も、コンテナの壁を越える入口になります。

コンテナの隔離技術：NamespaceとCgroups

コンテナのセキュリティを支える主要なLinuxカーネル機能を理解しましょう。

Namespace（名前空間）

プロセスに対し、システムリソースを独立した空間として見せる技術です。これにより、コンテナAからはコンテナBのプロセスが見えないようになります。

• PID Namespace: プロセスIDの隔離
• Net Namespace: ネットワークインターフェースの隔離
• Mnt Namespace: ファイルシステムマウントの隔離
• User Namespace: ユーザーIDとグループIDの隔離

このほかにもUTS（ホスト名）、IPC（プロセス間通信）、cgroupなどのNamespaceがあります。

Cgroups（Control Groups）

プロセスグループごとの物理リソース（CPU、メモリ、ディスクI/Oなど）の使用量を制限・隔離する技術です。特定のコンテナが暴走してCPUやメモリを占有し、他のコンテナやホストOSを停止させる「DoS攻撃（Denial of Service）」のような状態を防ぐために使います。

注意したいのは、Dockerの既定ではコンテナにリソースの上限がかからないことです。Dockerでは docker run の --memory・--cpus・--pids-limit で上限を設定します。Kubernetesでは、CPU・メモリはコンテナの resources.limits で、PID数はkubeletの podPidsLimit などで上限を設定します。こうして上限を設けることで、暴走したコンテナがホスト全体のリソースを使い果たすリスクを低減できます。

これらの技術用語そのものを暗記するよりも、「なぜコンテナ同士が互いのプロセスを見られないのか」「なぜリソース制限が必要なのか」を説明できることが大切です。その背景にあるのがこの仕組みです。

Docker環境における主要な脅威と対策

Docker単体のコンテナ環境において、具体的なリスクと対処方法を見ていきます。攻撃者の視点では、狙い所は「イメージ」「設定」「ランタイム」の3点に集約されます。

1. 信頼できないコンテナイメージのリスク（サプライチェーン攻撃）

コンテナの利点は、Docker Hubなどのレジストリから既存のイメージをダウンロードして即座に環境構築できる点です。しかし、公開イメージが安全である保証はありません。

主なリスク

• マルウェアの混入: 攻撃者が意図的にバックドアやクリプトマイナー（仮想通貨採掘ツール）を仕込んだイメージを公開しているケースがあります
• 脆弱なライブラリの残存: 公式イメージであっても、ベースとなっているOSやライブラリ（OpenSSLなど）に既知の脆弱性（CVE）が含まれていることがあります（修正版が未提供のものを含む）

対策：イメージスキャンと信頼済みレジストリの利用

イメージスキャンの実施

TrivyやClair、Docker Scoutなどのツールを使用し、イメージ内のパッケージ情報を脆弱性データベースと照合します。これをCI/CDパイプライン（開発からデプロイまでの自動化フロー）に組み込み、あらかじめ決めた拒否基準（例：修正版のある重大度の高い脆弱性）に該当するイメージのデプロイをブロックする運用が理想的です。ただし、スキャンで検出できるのは脆弱性データベースに登録済みの既知の脆弱性に限られるため、スキャン合格は脆弱性ゼロや安全の保証ではありません。

最小構成のイメージ利用

「Distroless」や「Alpine Linux」など、必要最小限のコンポーネントしか含まない軽量イメージを利用します。攻撃に利用できるシェルやツール（curlやwgetなど）が含まれていなければ、侵入後の活動や被害の拡大を困難にできます。なお、Distrolessの通常版はシェルやパッケージマネージャーを含まない（:debug 系のイメージはBusyBoxシェルを含む）のに対し、Alpine LinuxはBusyBox由来のシェル（sh）やwgetを含むため、「最小構成」の度合いは異なります。これは「攻撃対象領域（Attack Surface）の縮小」というセキュリティの基本原則に合致します。

2. 特権モードと不適切な権限管理

Dockerには --privileged というフラグがあります。これを付与してコンテナを起動すると、全Capabilitiesの付与、seccomp・AppArmorによる制限の無効化、ホストの全デバイスへのアクセスなどにより、コンテナ内のプロセスがホストとほぼ同等の操作を行えるようになります。これは実質的に、コンテナによる隔離を無効化する危険な設定です。

また、多くのコンテナはデフォルトで root ユーザーとして実行されます。デフォルトではCapabilitiesなどで権限の一部が制限されているものの、User Namespaceによるリマップ（userns-remap）やRootlessモードを使わない限り、コンテナ内のrootはホストOS上でも同じUID 0です。そのため、コンテナブレイクアウトが起きた場合、ホストのroot権限を奪われるおそれがあります。

対策：Least Privilege（最小権限の原則）の徹底

非特権ユーザーでの実行

Dockerfile内で USER 命令を使用し、root以外の一般ユーザーでアプリケーションを実行するように指定します。

Capabilities（ケーパビリティ）の制限

Linuxのroot権限を細分化した「Capabilities」機能を活用し、Docker実行時に --cap-drop=ALL ですべてのLinux capabilitiesを取り除いた後、必要な権限（例: --cap-add=NET_BIND_SERVICE）だけを付与します。

ファイルシステムの読み取り専用化

--read-only フラグを付けると、コンテナのルートファイルシステム全体が読み取り専用になります。ログや一時ファイルなど書き込みが必要なパスだけを、ボリュームや --tmpfs で個別に割り当てます。これにより、攻撃者が不正なファイルを設置したり、設定ファイルを改ざんしたりすることを困難にできます。

3. 機密情報の不適切な管理

開発中、APIキーやデータベースのパスワードをDockerfile内の環境変数（ENV）に直接記述してしまうケースが散見されます。Dockerデーモンを操作できるユーザーであれば docker inspect や docker history コマンドでこれらの値を閲覧でき、イメージを入手した第三者にも読み取られてしまいます。ビルド時だけ使う値をARG（ビルド引数）で渡す方法も、値がイメージの履歴に残るため安全ではありません。ビルド時に秘密情報が必要な場合は、BuildKitの RUN --mount=type=secret を使い、イメージのレイヤーに残さないようにします。

対策：シークレット管理機能の利用

機密情報はコードやイメージに埋め込まず、実行時に外部から注入する仕組みを利用します。Docker SwarmやKubernetesの「Secrets」機能、あるいはHashiCorp Vaultなどの専用ツールを使用します。コンテナへの渡し方は、環境変数よりもボリューム（tmpfs）としてマウントする方式を優先します。環境変数はプロセス情報やログ、エラー出力を経由して漏れやすいためです。これにより、イメージやコードに残った機密情報が漏洩するリスクを低減できます。

ただし、KubernetesのSecretsは既定ではetcdに暗号化されずに保存されます。マニフェストやAPI上でBase64エンコードされて見えるのは表現形式にすぎず、Base64は暗号化ではありません。etcdの保存時暗号化（Encryption at Rest）、最小権限のRBACによるSecretsへのアクセス制限、外部シークレットストア（HashiCorp Vaultやクラウドのシークレット管理サービス）を併用します。また、その名前空間でPodやDeploymentを作成できる者は、Secretをマウントしたワークロードを作ることでSecretの中身を読み出せます。Secretの get 権限だけでなく、ワークロードの作成権限も絞る必要がある点に注意してください。

Kubernetes（K8s）におけるセキュリティ要塞化

Docker単体ではなく、多数のコンテナを束ねて管理するKubernetes環境では、管理対象が広がるため、攻撃ベクトルも多岐にわたります。クラスター全体の要塞化が求められます。

1. Pod間通信の制御（Network Policies）

Kubernetesのデフォルト設定では、クラスター内のすべてのPod（コンテナの集合体）は、他のすべてのPodと通信可能です（フラットなネットワーク）。これは、WebサーバーのPodが侵害された場合、本来通信する必要のない内部のデータベースや管理用Podにまで攻撃が及ぶ（ラテラルムーブメント：横展開）リスクを意味します。

対策：Network Policyによるマイクロセグメンテーション

Kubernetesの NetworkPolicy リソースを使用し、Pod間の通信を許可リスト形式で制御します。たとえば「Frontend PodからBackend PodへのTCP 8080番ポートと、Backend PodからDB Podへの通信だけを許可する」といったルールを定義します。これは従来のファイアウォール設定を、アプリケーションの構成定義としてコード化するものです。

NetworkPolicyの動作で押さえておきたいのは次の2点です。

• 受信ポリシーに選択されたPodは許可リスト外の受信を拒否する: Ingress（受信）を対象とするポリシーの podSelector に選択されたPodは、適用される受信ポリシーのいずれでも許可されていない受信が自動的に拒否されます。複数のポリシーが同じPodを選択した場合は、許可ルールが足し合わされます（加算的）。Egress（送信）だけを対象とするポリシーに選択されたPodは、受信を制限されません
• Egressはその方向を対象とするポリシーで制限し、名前空間全体はdefault denyを土台にする: 受信・送信のそれぞれについて、その方向を対象とするポリシーに選択されていないPodは、従来どおりその方向の通信をすべて許可します。Egress（送信）も、対象Podを選んで policyTypes: [Egress] と許可ルールを定義すれば、その方向が許可リスト方式になります。名前空間全体を漏れなく原則遮断にする場合は、空の podSelector（名前空間内の全Podを選択）で通信を拒否するポリシー（default deny）を土台にし、必要な通信だけを個別に許可します

下の図では、BackendとDBに受信ポリシーを適用し、Frontend→Backend（TCP 8080）とBackend→DBの通信だけを許可しています。受信ポリシーを適用していないFrontendへの受信は制限されません。Frontend PodからDB Podへの直結は許可リストにないため拒否されます。同様に、侵害されたPodから、許可リストにない宛先（受信ポリシーが適用されたPod）への通信は拒否されます。ただし、侵害されたのがFrontendであればBackendのTCP 8080へは通信できますし、受信ポリシーが適用されていないPodへの通信は拒否されません。Webサーバーが乗っ取られても、DBへ直接たどり着けない（ラテラルムーブメントを防ぐ）ことがこの対策の狙いです。なお、NetworkPolicyはCalicoやCiliumなど、これに対応したネットワークプラグイン（CNI）が導入されていないと効果がありません。

2. Pod Security Standards (PSS) / Admission Controller

開発者がセキュリティ設定の甘いPod（特権モードなど）を勝手にデプロイしてしまうのを防ぐ仕組みが必要です。

Pod Security Standards（PSS） は、Podのセキュリティ設定の水準を「Privileged（制限なし）」「Baseline（既知の権限昇格を防ぐ最低限）」「Restricted（強く制限）」の3段階で定義したものです。かつてのPodSecurityPolicy（PSP）はKubernetes 1.25で削除されており、現在はPSSを組み込みの Pod Security Admission で適用します。

対策：Admission Controllerによるゲートキーパー機能

Admission Controller は、APIサーバーが受け付けたリクエストを、etcdに保存する前に検証・変更する仕組みです。代表的な手段は次のとおりです。

• Pod Security Admission（PSA）: Kubernetesに組み込まれたAdmission Controllerで、v1.25でGA（一般提供）となり、既定で有効です。ただし標準の既定値はprivilegedで、そのままでは制限がかかりません。名前空間に pod-security.kubernetes.io/enforce: restricted のようなラベルを付けるか、APIサーバー側のPSA設定（AdmissionConfiguration）でラベル未指定時のクラスター共通の既定値をbaseline/restrictedにすることで強制します。モードは enforce（違反を拒否）・audit（監査ログに記録）・warn（警告を表示）の3種類で、それぞれにPSSのレベル（privileged/baseline/restricted）を指定します
• OPA (Open Policy Agent) Gatekeeper・Kyverno: Admission Webhook（動的Admission制御）として動く外部ツールです。PSSの範囲を超えた独自ポリシー（許可するレジストリの限定、必須ラベルなど）を定義できます
• ValidatingAdmissionPolicy: CEL（Common Expression Language）で検証ルールを書く組み込みの仕組みで、外部Webhookを使わずに独自ポリシーを適用する選択肢になります

これにより、「rootユーザーでの実行禁止」「ホストパスのマウント禁止」といったポリシーに違反するPodの作成リクエストを、デプロイ前に自動的に拒否できます。なお、PSAの enforce はPodに対して適用されます。違反するDeploymentを作成した場合、Deploymentそのものは受け付けられ（warn モードを併用していれば作成時に警告が表示されます）、そこから生成されるPodの作成が失敗する、という挙動になる点に注意してください。

この仕組みは、開発者の自由度を損なうことなく、組織のセキュリティポリシーを強制的に適用する効果的な手段となります。

3. RBAC（Role-Based Access Control）の厳格化

Kubernetes APIへのアクセス権限管理は、クラスターセキュリティの根幹です。「誰が」「どのリソースに対して」「何ができるか」を厳密に定義する必要があります。

対策：最小権限のロール設計

ServiceAccountの管理

PodがAPIサーバーと通信するために使用するServiceAccountには、デフォルトで権限を与えすぎないようにします。不要であれば automountServiceAccountToken: false を設定し、トークンのマウント自体を無効化します。

RoleとClusterRole

開発者には特定のNamespace内での操作のみを許可する Role を割り当て、ClusterRoleBinding によってクラスター全体に権限が及ぶ ClusterRole（特に cluster-admin）の付与は厳重に制限します。過剰な権限付与は、内部脅威や認証情報の漏洩時に深刻な被害をもたらします。

4. イメージポリシーの強制

Kubernetesクラスターにデプロイ可能なイメージを制限することも重要です。信頼されたレジストリからのみイメージをプルするようにポリシーを設定し、未検証のイメージが本番環境にデプロイされることを防ぎます。

実現手段の例は次のとおりです。

• 署名検証: ビルド時にSigstore（cosign）でイメージに署名し、デプロイ時にKyverno（verifyImages）や、Ratify等と連携したOPA Gatekeeper、Sigstore policy-controllerで署名を検証して、署名のないイメージや信頼していない鍵で署名されたイメージを拒否します
• ダイジェスト指定: nginx:1.27 のようなタグは後から別のイメージに付け替えられるため、nginx@sha256:... のようにダイジェストで指定し、検証したイメージと同じ中身であることを保証します

コンテナ環境におけるログ監視とインシデント対応

防御を固めても、侵入される可能性はゼロではありません。コンテナは「短命（Ephemeral）」であるため、インシデント発生時にコンテナが破棄されていると、ログも失われることがあり、フォレンジック（原因究明）が困難になります。

ログの永続化と集約

コンテナの標準出力（stdout/stderr）に出力されたログは、Kubernetesの一般的な構成ではノード上のファイルとして保存されるだけで、Podが削除されたりノードが失われたりすると参照できなくなることがあります。外部への集約には、例えばFluentdやFluent Bit、Grafana Alloyなどのログ収集エージェントを各ノードにDaemonSetとして配置し、ElasticsearchやSplunk、クラウドのログ基盤（CloudWatch Logsなど）へ転送する方法を利用します（Dockerのログドライバーや、sidecarコンテナで収集する方法もあります）。

ログの集約により、以下のメリットが得られます：

• コンテナ破棄後もログが保持される
• クラスター全体のログを横断的に検索・分析できる
• 異常パターンの検知やアラート設定が可能になる
• コンプライアンス要件（監査ログの保存期間など）を満たすための前提になる

なお、コンテナのログだけでは「誰がどのリソースを作成・変更したか」はわかりません。Kubernetesでは、APIサーバーの監査ログ（Audit Policyで記録対象を定義）を別途有効化して収集します。

ランタイムセキュリティ監視

従来のアンチウイルスソフトは、コンテナ内部の挙動まで詳細に監視できない場合があります。

Falco

システムコールを監視し、「シェルが起動された」「機密ファイルへのアクセスがあった」「外部への不正な通信が発生した」といった異常検知を行うオープンソースツールです。コンテナやKubernetes環境に適したホストベースのIDS（侵入検知システム）として機能します。

Falcoは、事前に定義されたルールに基づいて、コンテナ内で発生する異常な動作をリアルタイムで検出します。例えば、Webサーバーコンテナ内で突然シェルが実行された場合、これは攻撃者がコマンド実行権限を奪取した可能性を示すため、即座にアラートを発生させます。

科目B（旧午後）に向けた記述対策のポイント

情報処理安全確保支援士試験の科目B（旧午後）で、コンテナセキュリティがテーマになった場合、以下のような観点を自分の言葉で説明できるようにしておくと、記述式の解答に応用できます。

1. 対策の必要性を理由付けする

設問例: なぜコンテナをrootユーザーで実行すべきではないのか？

解答例: コンテナブレイクアウトが発生した場合、攻撃者がホストOSの管理者権限を奪取し、システム全体を掌握されるリスクがあるため。

2. サプライチェーンリスクへの言及

設問例: 外部リポジトリのイメージを利用する際のリスクと対策は？

解答例: マルウェア混入や既知の脆弱性が含まれるリスクがあるため、利用前に脆弱性スキャンを実施し、組織内の信頼されたプライベートレジストリ経由でデプロイする。

3. 不変（Immutable）インフラストラクチャの理解

設問例: 稼働中のコンテナにパッチを適用せず、新しいイメージと入れ替える理由は？

解答例: 稼働中の変更は構成管理との乖離（ドリフト）を生み、再現性を損なうため。また、侵害されたコンテナを破棄し、脆弱性を修正したイメージに置き換えることで、攻撃者の足場を除去できるため。

4. 多層防御の観点

設問例: コンテナ環境におけるセキュリティ対策を複数層で説明せよ。

解答例: イメージレベルでの脆弱性スキャン、ランタイムレベルでの権限制限とリソース制限、ネットワークレベルでのマイクロセグメンテーション、運用レベルでのログ監視とインシデント対応という多層防御を実施する。

コンテナセキュリティのベストプラクティス

実務と試験対策の両面から、押さえておくべきベストプラクティスをまとめます。

イメージ管理

• 公式イメージや信頼できるソースからのみイメージを取得する
• 定期的にイメージをスキャンし、脆弱性を検出する
• 最小構成のベースイメージ（Alpine、Distrolessなど）を使用する
• イメージのタグには具体的なバージョンを指定し、latest タグは避ける（タグは付け替えられるため、本番ではダイジェスト @sha256: 指定が確実）
• イメージに署名し（Sigstore/cosignなど）、デプロイ時にKyverno（verifyImages）や、Ratify等と連携したOPA Gatekeeper、Sigstore policy-controllerで署名を検証する
• 不要なパッケージやツールを含まない専用イメージを作成する

ランタイムセキュリティ

• コンテナを非rootユーザーで実行する
• 特権モード（--privileged）の使用を避ける
• 必要最小限のCapabilitiesのみを付与する
• ファイルシステムを可能な限り読み取り専用にする
• リソース制限（CPU、メモリ）を適切に設定する

Kubernetesセキュリティ

• Network Policyを使用してPod間通信を制限する
• Pod Security Standardsを適用し、危険な設定を防ぐ
• RBACで最小権限の原則を徹底する
• ServiceAccountトークンの自動マウントを必要最小限に制限する
• Secretsを使用して機密情報を管理する
• Admission Controllerでポリシーを強制する（署名検証・許可レジストリの限定を含む）

監視と運用

• すべてのコンテナログを集約して永続化する
• ランタイムセキュリティツール（Falcoなど）で異常を検知する
• 定期的なセキュリティ監査を実施する
• インシデント対応手順を明確化し、訓練を行う
• CI/CDパイプラインにセキュリティチェックを組み込む

【演習】Docker・Kubernetesセキュリティ理解度チェック（全10問）

科目A-2（旧午前II）では、コンテナとVMの隔離の違い、Namespace・Cgroupsの役割、特権モードの危険性といった用語と仕組みが4択で、科目B（旧午後）では、侵害されたPodからの横展開やイメージ由来のリスクに対して、どの層でどう防ぐかを説明させる形で問われることが考えられます。定番のひっかけは、「Base64でエンコードされたSecretは暗号化されている」「NetworkPolicyはCNIがなくても効く」「Cgroupsは既定でリソースを制限してくれる」「PSAは有効なだけで強制される」といった思い込みです。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：コンテナセキュリティは多層防御の集大成

コンテナとKubernetesのセキュリティは、決して新しい概念だけで成り立っているわけではありません。

• OSレベル: カーネル機能（Namespace/Cgroups）と権限管理
• ネットワークレベル: マイクロセグメンテーションと通信制御
• アプリケーションレベル: 脆弱性管理とセキュアコーディング
• 運用レベル: ログ監視とCI/CDパイプラインでの自動化

これら、これまでに学んできたセキュリティの基本要素を、コンテナという新しいアーキテクチャに合わせて再構成し、隙間なく積み重ねていく「多層防御」のアプローチこそが正解です。

DockerやKubernetesは、開発スピードを飛躍的に向上させる強力な武器ですが、セキュリティ設定を誤れば、システム全体を危険にさらす可能性があります。本記事で解説した「イメージ」「ランタイム」「オーケストレーション」の3つの視点を持ち、試験対策はもちろん、実務でも安全なコンテナ環境を設計できるエンジニアを目指してください。

コンテナセキュリティの本質は、新しい技術への対応力だけでなく、セキュリティの基本原則を様々な環境に適用できる柔軟な思考力です。Namespace、Cgroups、Capabilitiesといった低レイヤーの仕組みから、Network Policy、RBAC、Admission Controllerといった高レイヤーの制御まで、各層での防御策を理解し、組み合わせることで、真に堅牢なコンテナ環境を実現できます。

情報処理安全確保支援士試験では、こうした多層防御の考え方と、各層での具体的な対策を適切に説明できる能力が評価されます。本記事の内容を基に、コンテナ特有のリスクと対策を自分の言葉で説明できるよう、理解を深めてください。

コンテナが動く基盤となるクラウド自体のセキュリティも、避けては通れない重要なテーマです。責任共有モデルはIaaS・PaaS・SaaSの違いとは？クラウドの責任共有モデルを完全図解、設定ミス対策はCASBとCSPMの違いとは?で解説しているので、あわせて確認しておきましょう。引き続き、合格に向けて知識の層を厚くしていきましょう。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• Kubernetes公式ドキュメント：Network Policies
• Kubernetes公式ドキュメント：Pod Security Admission
• Kubernetes公式ドキュメント：Secrets
• Docker公式ドキュメント：Resource constraints
• Docker公式ドキュメント：docker container run
• NIST SP 800-190 Application Container Security Guide
• CIS Docker Benchmark
• CIS Kubernetes Benchmark