コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプオンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure

セキュリティ・ミニキャンプオンライン 2021
Tsubasa Umeuchi
コンテナとその実行基盤を取り巻く

セキュリティの基礎と実践 (公開版)

View Slide

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (公開版) @ セキュリティ・ミニキャンプオンライン 2021 2
梅内翼 (Umeuchi Tsubasa)

‣ Twitter: @Sz4rny

所属

‣ 北陸先端科学技術大学院大学先端科学技術研究科
 
先端科学技術専攻ネットワーク・セキュリティ領域博士前期課程

活動

‣ SECCON Beginners 運営

‣ セキュリティ・キャンプ全国大会 2021 Bトラックチューター

著書

‣ 詳解セキュリティコンテスト CTFで学ぶ脆弱性攻略の技術 (マイナビ出版)
はじめに
自己紹介

View Slide

コンテナとコンテナオーケストレーションの技術的な原理を理解し、説明できる

コンテナを用いたシステムのデプロイ手法を実践できる

コンテナとその実行基盤を取り巻くセキュリティ上の脅威を理解し、説明できる

コンテナとその実行基盤を取り巻くセキュリティ上の脅威を緩和するための仕組みを実践できる
はじめに
本講義の目標
複雑かつ非常に速いスピードで進化を続ける今日のコンテナ関連技術と

そのセキュリティにキャッチアップするための素養を身に付ける
本講義の目標

View Slide

Part 1: コンテナとコンテナオーケストレーションの基礎

‣ コンテナ型仮想化技術を構成する技術要素を説明します

‣ コンテナ型仮想化およびコンテナ実行基盤のデファクトスタンダードである Docker, Kubernetes の概要を説明します

Part 2: コンテナを用いたシステムのデプロイ

‣ Docker および Kubernetes を用いたコンテナによるシステム (Web サーバ) のデプロイを実践します

Part 3: コンテナとその実行基盤を取り巻くセキュリティの基礎

‣ コンテナオーケストレーション環境の各構成要素に存在するセキュリティ上の脅威を分類し、説明します

Part 4: コンテナとその実行基盤を取り巻くセキュリティの実践

‣ 脆弱性が存在するコンテナがデプロイされることを防止するための仕組みを実践します

‣ ポリシーに反するワークロードがデプロイされることを防止するための仕組みを構築します

Part 5: おわりに

‣ 本日の講義内容を総括するとともに、今後の学習に向けた指針を提示します
はじめに
本日の講義の流れ

View Slide

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 @ セキュリティ・ミニキャンプオンライン 2021 5
本資料はセキュリティ・ミニキャンプオンライン 2021で実施した講義「コンテナとその実行基盤
を取り巻くセキュリティの基礎と実践」の講義資料を一部編集して公開したものです

‣ 参照: https://www.security-camp.or.jp/minicamp/online2021.html

本資料の利用は CC BY-NC-SA 4.0 ライセンスに基づきます

‣ 参照: https://creativecommons.org/licenses/by-nc-sa/4.0/deed.ja
はじめに
公開版向けの留意事項

View Slide

コンテナとコンテナオーケストレーションの基礎
コンテナ型仮想化技術を構成する技術要素の基礎を紹介します。また、コンテナ型仮想化
およびコンテナ実行基盤のデファクトスタンダードである Docker, Kubernetes の概要を
説明します。
Part 1

View Slide

コンテナ型仮想化技術 (Container-based Virtualization)

‣ コンピュータシステムにおけるリソースをコンテナという単位で仮想化する技術の総称

仮想化 (Virtualization)

‣ コンピュータシステムにおけるリソースを抽象化することで、物理的な構成に縛られることなく、
 
ソフトウェアに対して柔軟にリソースを提供できるようにする技術の総称

‣ ソフトウェアに対して独占的に利用できるリソースが実際より多く存在するかのように見せることができる

例: サーバ仮想化

‣ ある物理サーバ上で複数の仮想的なサーバを
 
稼働させる

‣ ソフトウェアから見ると、自分がそのサーバを
 
独占的に利用しているかのように見える
コンテナ型仮想化技術の基礎
物理サーバ
仮想サーバ仮想サーバ
ソフトウェアソフトウェア
ɾɾɾ
ɾɾɾ
リソースを利用
仮想化

View Slide

VM 型仮想化

‣ コンピュータシステム全体を仮想化する方式

‣ ソフトウェアに対してコンピュータシステム全体を独占しているかのように見せかける

‣ ホスト OS 上で仮想化ソフトウェアを動作させるホスト OS 型と
 
ホスト OS を介在させないハイパーバイザ型が存在する

‣ OS 自体が隔離されているためオーバーヘッドが大きいが、隔離性は高い

コンテナ型仮想化

‣ カーネルの機能を利用して OS レベルの仮想化を提供する方式

‣ ソフトウェア (プロセス) に対して OS を独占しているかのように見せかける

- カーネルから見ると、コンテナランタイム上で稼働するコンテナはただのプロセス
 
‣ 各コンテナは同一の OS 上で動作しているため処理のオーバーヘッドは小さいが、隔離性は低い
仮想化技術の種別

View Slide

図解: 仮想化技術の種別
物理サーバ
ホスト OS
仮想化ソフトウェア
ゲスト OS
ソフトウェア
ソフトウェア
VM / ホスト OS 型

(例: VirtualBox)
物理サーバ
ホスト OS
ハイパーバイザ
ゲスト OS
ソフトウェア
VM / ハイパーバイザ型

(例: ESXi, Xen)
物理サーバ
ホスト OS
コンテナエンジン
コンテナ
ソフトウェア
ライブラリ
アプリケーション
コンテナ型

(例: Docker)

View Slide

コンテナ型仮想化の特徴

‣ VM 型と異なり、各コンテナにはそれ専用のゲスト OS が用意されない

‣ 各コンテナはホスト OS のカーネルを共有して利用する

コンテナ型仮想化の歴史
コンテナ型仮想化の特徴と歴史
年代名称概要
2000年 FreeBSD jail FreeBSD ベースのシステムを jail という独立したシステムに分割する
2004年 Solaris Zone Soraris システムを Zone と呼ばれる単位に分割し、独立した環境を提供する
2005年 OpenVZ RHEL システム上で独立した Linux のインスタンスを稼働させる
2014年 LXC (Linux Containers) Linux システム上で独立した Linux のコンテナを稼働させる
2013年 Docker コンテナのイメージ共有やビルド、デプロイに必要な一連の機能を提供する

View Slide

コンテナに提供するリソースの隔離

‣ コンテナとして稼働するプロセスが他のプロセスに影響を及ぼさないようにする

‣ リソースの隔離は Namespace を利用して実現される

- ある Namespace 内のプロセスは異なる Namespace のリソースにアクセスすることができない

- PID Namespace, Network Namespace, IPC Namespace, etc.

コンテナに提供するファイルシステムの隔離

‣ ファイルシステムの隔離は pivot_root システムコールを利用して実現される

- あるプロセスのファイルシステムにおけるルート (/) のマウントポイントを入れ替える

コンテナに提供するリソースの制限

‣ あるコンテナが物理ホストのリソースを過剰に消費しないようにする

‣ 特定のプロセス群が利用可能なリソースを制限する仕組みである cgroups を利用して実現される
コンテナ型仮想化を支える技術 (Linux の機能を例に)

View Slide

Docker (https://www.docker.com/)

‣ コンテナ型仮想化によるアプリケーションのデプロイを包括的にサポートするプラットフォーム

- コンテナイメージのビルド (Build) や共有 (Ship) 、デプロイ (Run) に必要な一連の機能を提供する

‣ Docker Hub というコンテナレジストリを用いることで作成したコンテナイメージの共有が可能

Docker コンテナのライフサイクル
Docker の概要、主なコマンド、ライフサイクル
Docker
fi
le
コンテナイメージ Created
Stopped
Running Paused
Deleted
docker build
docker create docker start
docker pause
docker unpause
docker start
docker stop
docker rm
docker rm

View Slide

イメージのビルド

‣ コンテナイメージを生成するために必要な命令を Docker
fi
le に記述し、
 
docker build コマンドを実行することでコンテナイメージのビルドが可能
 
‣ Docker
fi
le では、主に以下の命令を利用してコンテナイメージの定義を行う

- FROM … ベースイメージの指定

- RUN … 現在の状態 (レイヤ) にてコマンドを実行し、その結果を次のステップに持ち越す

- COPY … ホスト上のファイルやディレクトリをコンテナイメージのファイルシステムにコピーする

- CMD … コンテナ起動時にデフォルトで実行するコマンドを指定する

ハンズオン: イメージのビルドとコンテナの実行

‣ 実行されると sl コマンドを実行するコンテナをビルドする
Docker イメージのビルドとコンテナの実行
Docker
fi
le 実行するコマンド

View Slide

Docker コンテナが実行されるまでの流れ (docker run … を実行した場合)

1. Docker Client が dockerd の REST API に対してリクエスト (docker run …) を送信する

2. dockerd は High-level Runtime に対して gRPC 経由で実行すべきコンテナの情報を伝える

3. High-level Runtime は Low-level Runtime に対して OCI という JSON 形式の仕様に基づいて
 
実行すべきコンテナの情報を伝える

4. Low-level Runtime は実際にコンテナを実行する
Docker コンテナが実行されるまでの流れ
Docker Client

(例: Docker CLI)
dockerd

(Docker Daemon)
High-level Runtime

(例: Containerd)
Low-level Runtime

(例: runc)
REST API gRPC
OCI
 
(JSON) 実行
Docker Container

View Slide

High-level Runtime

‣ CRI (Container Runtime Interface) Runtime とも呼ばれる

‣ クライアントからのリクエストの受け付けやコンテナイメージの管理、
 
Low-level Runtime に対するコンテナ実行の指示等を担当する

‣ 例: Containerd, CRI-O, Frakti, etc.

Low-level Runtime

‣ OCI (Open Container Initiative) Runtime とも呼ばれる

‣ High-level Runtime から受け取った指示に基づいて、実際にコンテナを実行する

‣ 例: runc, gVisor, Kata Containers, Nabla Containers, etc.

なぜこれらのランタイムは分離されているのか？

‣ 担当すべき責務に基づいて仕様を分けることで、機能の分担が明確になる

‣ ユースケースに応じた最適な Runtime を都度選択することができる
High-level Runtime と Low-level Runtime

View Slide

コンテナを用いたシステムのデプロイにおける課題

‣ システムのデプロイにおいて「単一のコンテナを実行するだけ」というケースはほぼ存在しない

‣ 高可用性を実現するため同種のコンテナを異なるノードに複数個同時にデプロイしたり、コンテナにアクセスするための
サービスディスカバリが求められたり、コンテナの死活監視を行ったりする必要が生じる

‣ 何千、何万ものコンテナが同時に動作している環境において、これらを人手で行うのは不可能

コンテナオーケストレーションの概要

‣ コンテナを用いた大規模な環境において、コンテナを動的に管理するツールやその手法のこと

‣ コンテナの管理を任せることで、運用者の負担の軽減や、構成の迅速な変更が可能になる

- i.e., Cloud Native なシステム構成の実現につながる
コンテナオーケストレーションの基礎
Node
Node
管理
Node
Node
管理
理想状態
コンテナ

オーケストレータ
運用者
運用者

View Slide

コンテナオーケストレーションに求められる役割
コンテナのスケーリングと負荷分散

‣ 想定される負荷等に応じて同種のコンテナを複製 (replication) する

- 例: あるコンテナへのリクエスト数が増加傾向にある場合、そのコンテナの数を増やし負荷分散する

コンテナのスケジューリング

‣ あるコンテナの実行に最も適したノードを自動的に選択する

- 例: リソースに余裕があるノード、キャッシュがあるノード、同種のコンテナが実行されていないノード

コンテナのセルフヒーリング

‣ あるコンテナが何らかの原因で終了した時、そのコンテナを何らかの方法で復旧させる

- 例: コンテナを実行しているノードに障害が発生した場合、そのコンテナを他のノードに移して実行する

サービスディスカバリの提供

‣ 特定の条件を持つコンテナに対するルーティングの設定を一元的に管理する

- 例: サービスを提供しているコンテナへ s.example.com という名前でアクセスできるようにする
S

View Slide

Kubernetes の概要
Kubernetes

‣ コンテナ化されたワークロードやサービスを管理するためのコンテナ実行基盤で、
 
複数台のノードによって構成されるクラスタ上でコンテナを実行する

‣ コンテナオーケストレータのデファクトスタンダード

‣ Google のクラスタ管理システムである Borg を前身とする

Kubernetes が提供する機能

‣ YAML を用いた宣言的なワークロードの管理

‣ ワークロードの世代管理や自動スケール

‣ ワークロードのスケジューリング

‣ サービスディスカバリの提供

‣ クラウドサービスとの連携

‣ etc.

View Slide

Kubernetes の概要図 (1/3)
kube-apiserver
kube-scheduler
kube-controller-manager
etcd
Master Node
kubelet
kube-proxy Runtime
Worker Node
Master Node

‣ Control Plane とも呼ばれる

‣ クラスタ全体の管理を行う

- 障害が発生するとクラスタ全体に影響が波及する

‣ 高可用性を維持するため、
 
複数台構成にするのが一般的

Worker Node

‣ コンテナが実際にデプロイされるノード

‣ 後述する kubelet が自身に割り当てられた
 
ワークロードを定期的に確認し、
 
未実行のものがあれば Runtime に実行を
 
指示する

View Slide

etcd

‣ クラスタ全体の構成情報を
 
永続化する分散型データストア

kube-apiserver

‣ etcd の情報にアクセスするための
 
API を提供するコンポーネント

kube-scheduler

‣ 未スケジュールの Pod を
 
いずれかの Worker Node に割り当てる


‣ クラスタにデプロイされたリソースが
 
理想状態と一致するように調整する

- Reconciliation Loops (後述)
kube-apiserver
kube-scheduler
etcd
Master Node
kubelet
kube-proxy Runtime
Worker Node

View Slide

kubelet

‣ Worker Node に配置されるエージェント

‣ 自身に割り当てられたワークロードを定期的
に確認し、未実行のものがあれば Runtime に
実行を指示する

‣ Node や Pod の状態監視も行う

kube-proxy

‣ サービスディスカバリの構成に応じて
 
トラフィックを適切にルーティングする

Runtime

‣ kubelet からの指示でワークロードを実行する

‣ デフォルトは runc
kube-apiserver
kube-scheduler
etcd
Master Node
kubelet
kube-proxy Runtime
Worker Node

View Slide

Kubernetes における主なリソース
Pod

‣ 1つ以上のコンテナから構成されるリソース

‣ Kubernetes においてワークロードをデプロイする際の最小単位

ReplicaSet

‣ 指定した Pod がクラスタ内で定義された個数動作していることを保証するリソース

‣ Reconciliation Loop に基づき、動作中の Pod の個数を調整する

Deployment

‣ ReplicaSet の世代管理やデプロイの管理を行うためのリソース

‣ Pod の定義が変更された場合にすべてのレプリカを順番に更新する等の動作を行う

Service

‣ デプロイされた Pod にアクセスするためのエンドポイントを提供するリソース

‣ DNS による名前解決やクラウドサービスが提供するロードバランサとの連携等が可能

View Slide

Kubernetes と Reconciliation Loop (1/3)
Reconciliation Loop の概要

‣ Controller が API Server に対して理想状態を定期的に確認 (Observe) し、
 
現状と理想状態を突き合わせる (Analyze)

‣ 差異がある場合には、その差異を解消する処理を実行 (Act) する
理想状態現状
コンテナが ? 個稼働しているコンテナが M 個稼働している
⓪ 初期状態
コンテナが N 個稼働しているコンテナが M 個稼働している
① Observe
コンテナが N 個稼働しているコンテナが M 個稼働している
② Analyze
コンテナが N 個稼働しているコンテナが N 個稼働している
③ Act

View Slide

Reconciliation Loop の例

1. 「システムを提供するコンテナのレプリカが同時に5個稼働している」という理想状態を定義する

2. Controller は API Server に対してのレプリカの個数の理想状態を問い合わせる (Observe)

3. API Server はのレプリカの個数の理想状態を5個とレスポンスする

4. Controller は現状と理想状態を突き合わせる (Analyze)

5. のレプリカの個数が1個足りていないので、Controller はを新たに1つデプロイする (Act)

6. が新たに1つデプロイされると、のレプリカが同時に5個稼働している状態が実現される
S C
C
C
C C
C C
etcd
Controller
API Server Cluster
ཧ૝ͷϨϓϦΧ਺: 5
ݱঢ়ͷϨϓϦΧ਺: 4
1
2
3
4
5

View Slide

Reconciliation Loop の例

1. 「システムを提供するコンテナのレプリカが同時に5個稼働している」という理想状態を定義する

2. Controller は API Server に対してのレプリカの個数の理想状態を問い合わせる (Observe)

3. API Server はのレプリカの個数の理想状態を5個とレスポンスする

4. Controller は現状と理想状態を突き合わせる (Analyze)

5. のレプリカの個数が1個足りていないので、Controller はを新たに1つデプロイする (Act)

6. が新たに1つデプロイされると、のレプリカが同時に5個稼働している状態が実現される
S C
C
C
C C
C C
etcd
Controller
API Server Cluster
ཧ૝ͷϨϓϦΧ਺: 5
ݱঢ়ͷϨϓϦΧ਺: 5
1
2
3
4
5
6

View Slide

kubectl
kubectl

‣ Kubernetes の API Server にリクエストを行うコマンドラインツール

リファレンス

‣ kubectl get <リソース種別> … 指定したリソースの一覧を取得する

‣ kubectl describe <リソース種別> <名前> … 指定した名前を持つリソースの情報を詳細表示する

‣ kubectl apply -f <ファイル名> … ファイルで定義したリソースを適用する

‣ kubectl delete -f <ファイル名> … ファイルで定義したリソースを削除する

コマンドの例

‣ kubectl get nodes … ノードをすべて取得する

‣ kubectl describe pod … 指定した Pod の情報を詳細表示する

‣ kubectl apply -f foo.yaml … foo.yaml 内に定義されたリソースを適用する

‣ kubectl delete -f foo.yaml … foo.yaml 内に定義されたリソースを削除する

View Slide

コンテナを用いたシステムのデプロイ
Docker および Kubernetes を用いたコンテナによるシステム (Web サーバ) のデプロイ
を実践します。
Part 2

View Slide

本パートのハンズオンで実施すること
Docker の演習

‣ Docker
fi
le を用いたコンテナイメージの定義とビルド

‣ ビルドしたコンテナイメージの実行

Kubernetes の演習

‣ クラスタの展開

‣ Pod のデプロイ

‣ Deployment のデプロイと自動スケールの動作確認

‣ Service のデプロイと動作確認

View Slide

演習用データが格納されたリポジトリのクローン
事前準備
# git clone https://github.com/Szarny/online_minicamp_2021_container_security.git
Bash

View Slide

ハンズオン: Docker イメージのビルド

‣ ex1_docker ディレクトリ内のデータを利用します

以下の条件を満たすコンテナイメージを生成する Docker
fi
le を作成し、ビルドしてください

‣ ベースイメージは nginx:latest とする

‣ ビルドの過程で同ディレクトリ内の index.html を /usr/share/nginx/html ディレクトリにコピーする

‣ イメージ名は ex1_docker とする
# cd ex1_docker
Bash

View Slide

以下の条件を満たすコンテナイメージをビルドしてください

‣ ベースイメージは nginx:1.21 とする

‣ ビルドの過程で同ディレクトリ内の index.html を /usr/share/nginx/html ディレクトリにコピーする

‣ イメージ名は ex1_docker:1.0 とする

解答
FROM nginx:1.21

COPY ./index.html /usr/share/nginx/html
Docker
fi
le
# docker build -t ex1_docker:1.0 .
Bash

View Slide

ハンズオン: Docker コンテナの実行

‣ 先ほどビルドした ex1_docker イメージをもとにコンテナを実行してください

‣ 実行時にポートフォワーディングを行ってください

- ホスト側ポートは 8080、コンテナ側ポートは 80 とします

‣ コンテナを実行後、ブラウザで http://localhost:8080 にアクセスし、
 
index.html がレスポンスされることを確認してください

View Slide


‣ 先ほどビルドした ex1_docker イメージをもとにコンテナを実行してください

‣ 実行時にポートフォワーディングを行ってください

- ホスト側ポートは 8080、コンテナ側ポートは 80 とします

‣ コンテナを実行後、ブラウザで http://localhost:8080 にアクセスし、
 
index.html がレスポンスされることを確認してください

解答
# docker run -p 8080:80 ex1_docker
Bash

View Slide

ハンズオン: Kubernetes in Docker を用いた Kubernetes クラスタの展開

‣ ex2_kubernetes ディレクトリ内のデータを利用します

以下のコマンドを実行して Kubernetes クラスタを展開してください

備考

‣ これより先のハンズオンでなにか問題があれば、以下のコマンドを実行すればクラスタを削除できます
ハンズオン: Kubernetes in Docker を用いた Kubernetes クラスタの展開 (1/2)
# cd ex2_kubernetes
Bash
# kind create cluster --config cluster.yaml
Bash
# kind delete cluster
Bash

View Slide

以下のような出力が確認できれば成功です
ハンズオン: Kubernetes in Docker を用いた Kubernetes クラスタの展開 (2/2)
# kind create cluster --config cluster.yaml

Creating cluster "kind" ...

✓ Ensuring node image (kindest/node:v1.21.1) 🖼

✓ Preparing nodes 📦 📦 📦

✓ Writing configuration 📜

✓ Starting control-plane 🕹

✓ Installing CNI 🔌

✓ Installing StorageClass 💾

✓ Joining worker nodes 🚜

Set kubectl context to "kind-kind"

You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a nice day! 👋
Bash

View Slide

ハンズオン: Node の確認

‣ 右記のコマンドを実行し、Node の一覧を取得してください

‣ 何という名前の Node が実行されていますか？

‣ Master Node と Worker Node はそれぞれいくつ存在しますか？

ハンズオン: Pod の確認

‣ 右記のコマンドを実行し、すべての Pod の一覧を取得してください

‣ 何という名前の Pod が実行されていますか？

‣ 気になる Pod について検索し、その役割を調べてください
ハンズオン: クラスタの初期状態の確認
# kubectl get node
Bash
# kubectl get pod -A
Bash

View Slide

ハンズオン: Node の確認

‣ 右記のコマンドを実行し、Node の一覧を取得してください

‣ 何という名前の Node が実行されていますか？

- kind-control-plane, kind-worker, kind-worker2
 
‣ Master Node と Worker Node はそれぞれいくつ存在しますか？

- Master Node は 1 つ、Worker Node は 2 つ

ハンズオン: Pod の確認

‣ 右記のコマンドを実行し、すべての Pod の一覧を取得してください

‣ 何という名前の Pod が実行されていますか？

- coredns-xxx-yyy

- etcd-kind-control-plane

- kube-apiserver-kind-control-plane

- kube-scheduler-kind-control-plane

- ...
ハンズオン: クラスタの初期状態の確認 (解答)
# kubectl get node
Bash
# kubectl get pod -A
Bash

View Slide

ハンズオン: Pod のデプロイ

‣ 右記の内容を pod.yaml に記述してください

‣ 下記のコマンドを実行し、Pod をデプロイしてください

‣ 正しくデプロイされていることを確認してください

‣ 確認ができたら、Pod を削除してください
ハンズオン: Pod のデプロイ
apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

spec:

containers:

- name: nginx-container

image: nginx:1.21
pod.yaml
# kubectl apply -f pod.yaml
Bash
# kubectl get pod
Bash
# kubectl delete -f pod.yaml
Bash

View Slide

ハンズオン: Deployment のデプロイ

‣ 右記の内容を deployment.yaml に記述してください

‣ 下記のコマンドを実行し、Deployment をデプロイしてください

‣ 正しくデプロイされていることを確認してください

‣ Pod の数が .spec.replicas に指定した数と
 
一致していることを確認してください
ハンズオン: Deployment のデプロイ
apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deployment

spec:

replicas: 3

selector:

matchLabels:

name: nginx-pod

template:

metadata:

labels:

name: nginx-pod

spec:

containers:

- name: nginx

image: nginx:1.21
deployment.yaml
# kubectl apply -f deployment.yaml
Bash
# kubectl get deployment
Bash
# kubectl get pod
Bash

View Slide

ハンズオン: Deployment の編集

‣ .spec.replicas の値を 5 に書き換えてください

‣ 下記のコマンドを実行し、Deployment を再デプロイしてください

‣ Pod の数が .spec.replicas に指定した数 (=5) と
 
一致していることを確認してください
ハンズオン: Deployment の編集
apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deployment

spec:

replicas: 5

selector:

matchLabels:

name: nginx-pod

template:

metadata:

labels:

name: nginx-pod

spec:

containers:

- name: nginx

image: nginx:1.21
deployment.yaml
# kubectl apply -f deployment.yaml
Bash
# kubectl get pod
Bash

View Slide

ハンズオン: Service のデプロイ

‣ 右記の内容を service.yaml に記述してください

‣ 下記のコマンドを実行し、Service をデプロイしてください

‣ Service の Endpoints にデプロイした Pod の IP アドレスが
 
指定されていることを確認してください
ハンズオン: Service のデプロイ
apiVersion: v1

kind: Service

metadata:

name: nginx-service

spec:

type: ClusterIP

ports:

- name: http

protocol: TCP

port: 80

targetPort: 80

selector:

name: nginx-pod
service.yaml
# kubectl apply -f service.yaml
Bash
# kubectl describe service nginx-service

...

Endpoints:
10.244.1.10:80,10.244.1.11:80,10.244.1.12:80 + 2 more...

...
Bash

View Slide

ここまででデプロイしたもの

‣ Nginx の Pod (レプリカ数 5)

‣ 上記の Pod を対象とした ClusterIP Service
ここまでの流れのおさらい
Worker Node Worker Node
ClusterIP Service

(nginx-service:80 → :80)

View Slide

ハンズオン: Service へのアクセス

‣ 下記のコマンドを実行し、Nginx からのレスポンスが表示されることを確認してください

- curl.sh に同一のコマンドを記載しています
ハンズオン: Service へのアクセス
# kubectl run -it --rm curl --restart=Never --image=curlimages/curl -- http://nginx-service:80
Bash
Worker Node Worker Node
ClusterIP Service

(nginx-service:80 → :80)
kubectl run

View Slide

ハンズオン: 後片付け

‣ 確認が終了したら、Deployment と Service を削除してください
ハンズオン: 後片付け
# kubectl delete -f deployment.yaml

# kubectl delete -f service.yaml
Bash

View Slide

補足情報: Pod マニフェストの Tips
apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

spec:

containers:


image: nginx:1.21

resources:

limits:

cpu: 1000m

memory: 256Mi

requests:

cpu: 1000m

memory: 256Mi
リソースの指定
apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

spec:

containers:


image: nginx:1.21

securityContext:

privileged: false

allowPrivilegeEscalation: false

runAsUser: 1000

readOnlyRootFilesystem: true
Security Context の指定

View Slide

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (公開版) @ セキュリティ・ミニキャンプオンライン 2021
Security Context

‣ Pod やコンテナに指定可能なセキュリティ関連のオプション
46
補足情報: Security Context に指定可能なオプションの例
オプション名概要
runAsUser コンテナを実行するプロセスの UID を数値で指定する
runAsGroup コンテナを実行するプロセスの GID を数値で指定する
runAsNonRoot 値が true であればコンテナを root として実行しないことを指定する
privileged コンテナに特権 (ホスト上の root と同等の権限) を与えるかどうかを指定する
allowPrivilegeEscalation コンテナのプロセスが親プロセス以上の権限を取得できるかどうかを指定する
readOnlyRootFilesystem 値が true であればルートファイルシステムが読み取り専用になる
capabilities Capability (root 権限を細分化したもの) の付与、非付与を指定する

View Slide


セキュリティの基礎
コンテナやコンテナオーケストレーション環境におけるセキュリティの原則について紹介
するとともに、存在するセキュリティ上の脅威を分類し、説明します。
Part 3

View Slide

選考課題問5 より抜粋

‣ ... システムがコンテナとして展開される環境において懸念されるセキュリティ上の脅威を ...
 
取り上げ、その原因や影響、対策等について論じてください ...

グループワーク

‣ ここまでの講義を通して学んだ知識をもとに、
 
(事前課題に取り組んだ人も改めて) どのような脅威が存在しそうか個人で検討してください

‣ 検討した内容をチーム内で発表し、議論してください
 
検討する際のヒント

‣ VM 型仮想化と比較して、コンテナ型仮想化の隔離性はどうだったでしょうか

‣ コンテナイメージは常に安全だと言えるでしょうか

‣ コンテナ間を流れるトラフィックはどのような経路をたどるでしょうか

‣ オーケストレータのコンポーネントや API に誰でもアクセスができる環境だと何が起こるでしょうか

‣ あなたがオーケストレータの運用担当者だとすると、どのようなコンテナがデプロイされると困るでしょうか
コンテナとその実行基盤を取り巻くセキュリティの基礎
グループワーク: コンテナを利用する環境において懸念される脅威
講義終了後にここで検討した内容を改めて振り返ってみてください

View Slide

情報セキュリティの定義 (JIS X5080 より)

‣ 情報システムの機密性、完全性、可用性を維持すること

- 機密性 ... 権限を有する主体のみが情報にアクセスできる

- 完全性 ... 情報やその処理が正確である (≒ 情報の改ざんや破壊が存在しない、できない)

- 可用性 ... 権限を有する主体はいつでも情報にアクセスできる

リスクアセスメント

‣ ... 危険性や有害性の特定、リスクの見積り、優先度の設定、リスク低減措置の決定の一連の手順 ... [2]

- 対象とするシステムがどのような要素で構成されているのか

- その構成要素それぞれに対してどのような脅威が想定されるのか

- 攻撃を困難にするために、どのような措置を行うことが有効なのか

‣ 参照: https://www.ipa.go.jp/
fi
les/000013299.pdf

コンテナやコンテナオーケストレータを活用してサービスを提供するシステムは、
 
往々にしてシステム内の構成要素の数が多く、その関係性も複雑である

‣ よって、対象となるシステムを抽象的なモデルに落とし込んでリスクを見積もることが重要
情報セキュリティの基礎のおさらい

View Slide

4C モデル

‣ クラウドネイティブ環境におけるセキュリティモデルの一種

‣ 参照: https://kubernetes.io/docs/concepts/security/overview/

Cloud

‣ Cluster を展開するクラウドサービス上の基盤

Cluster

‣ Container を管理・運用するコンテナオーケストレータ

‣ オーケストレーションのための様々なコンポーネントを含む

Container

‣ Code を含み、Cluster 上で実行されるコンテナ

‣ Code を実行するためのライブラリを含む

Code

‣ Container に含まれるアプリケーションコード
クラウドネイティブセキュリティにおける 4C モデル
 
Cloud
 
Cluster
 
Container
 
Code

View Slide

Cluster

‣ Container を管理・運用する
 
コンテナオーケストレータ

- 本講義では Kubernetes が対象
 
‣ オーケストレーションのための
 
様々なコンポーネントを含む

脅威の例

‣ etcd 内のデータが暗号化されておらず、
 
直接アクセスするとデータがすべて読める

‣ kube-apiserver における認証認可の
 
設定に不備がある

‣ kubelet の API に自由にアクセスできる
4C モデルにおける Cluster
kube-apiserver
kube-scheduler
etcd
Master Node
kubelet
kube-proxy Runtime
Worker Node

View Slide

Container

‣ Code を含み、Cluster 上で実行されるコンテナ

‣ Code を実行するためのライブラリを含む

脅威の例

‣ ライブラリに既知の脆弱性が存在する

‣ コンテナイメージが改ざんされている

‣ コンテナを管理する API に自由にアクセスできる

‣ コンテナがホストのリソースを過剰に消費する
4C モデルにおける Container
物理サーバ
ホスト OS
コンテナエンジン
コンテナ
ソフトウェア
ライブラリ
アプリケーション

View Slide

NIST SP 800-190

‣ NIST (米国標準技術研究所) が公開しているコンテナセキュリティに関する文書

‣ コンテナ技術の基礎や主なリスク、その対策が記載されている

NIST SP 800-190 で定義されている対象別の主なリスク
NIST SP 800-190 で定義されているコンテナ技術関連のリスク
• イメージ内に既知の脆弱性が存在する

• イメージ内に機密情報が含まれている

• 信頼できないイメージを利用している
Image
• レジストリとの通信が暗号化されていない

• 既知の脆弱性が存在するイメージを格納している

• 認証認可を適切に実施していない
Registry
• クラスタのユーザに過剰な権限を付与している

• 様々な機密レベルのトラフィックが混在する

• クラスタを構成するノードが脆弱である
Orchestrator
• ランタイムの脆弱性によるブレイクアウト

• コンテナに対する特権の付与

• 検査を実施していないコンテナがデプロイされている
Container

View Slide

Defense in Depth (多層防御)

‣ システム内の複数のレイヤーにおいて対策を講じることで、
 
あるレイヤーの対策が破られても他のレイヤーの対策が有効に働くようにする

‣ 例: etcd 内の情報の漏洩を防ぐために、Master Node へのリモートアクセスを
 
遮断するとともに、etcd 内の情報を暗号化する

Least Privilege (最小権限の原則)

‣ 必要最小限のデータや機能にのみアクセス可能な権限を付与する

‣ 例: Pod の状態を監視するアプリケーションには
 
Pod の Read 権限のみを与える (Write 権限を与えない)

Limiting the Attack Surface (攻撃対象領域の削減)

‣ 動作しているシステムを可能な限りシンプルに保ち、
 
余計なコンポーネントや機能を動作させない

- 何も存在しなければそもそも攻撃のしようがない
複雑なシステムのセキュリティにおける汎用的な原則
Read 権限
Write 権限

View Slide

コンテナ型仮想化の概要図
コンテナ型仮想化の概要を振り返り
Client Runtime
リクエスト実行
Container
コンテナイメージ

の読み込み
Container

Registry

View Slide

コンテナにおける脅威: API の不適切な公開

‣ 概要

- Docker API のエンドポイントは Unix ドメインソケットか
 
TCP ソケットを用いて接続することができる

- TCP ソケットを用いる場合は mTLS によって
 
クライアント認証を行う必要がある

- クライアント認証が行われない環境の場合、任意のユーザが Docker API にアクセスし、
 
自由にコンテナを起動したり削除したりすることができる

‣ 対策

- リモートから dockerd に接続しない場合は TCP ソケットの利用を許可しない

- mTLS によるクライアント認証を実施する (あるいは、SSH 経由での接続に限り許可する)
コンテナにおける脅威: API の不適切な公開

View Slide

コンテナにおける脅威: 既知の脆弱性が存在するコンテナイメージの利用

‣ 概要

- コンテナイメージは目的とするアプリケーションを
 
動作させるためのライブラリを含む

- このアプリケーションが依存するライブラリに
 
既知の脆弱性が存在する恐れがある

- 既知の脆弱性が存在するコンテナイメージを利用した場合、
 
当該脆弱性を用いてアプリケーションが侵害されたり、
 
最悪の場合はホストにまで影響が波及する場合がある
 
(特に、特権コンテナとして動作させていたり、ホスト上のファイルシステムをマウントしていたりする場合)

‣ 対策

- コンテナイメージ向けの脆弱性スキャナを利用し、デプロイ前に脆弱性の有無を検証する
コンテナにおける脅威: 既知の脆弱性が存在するコンテナイメージの利用

View Slide

Clair (https://github.com/quay/clair)

‣ Project Quay からリリースされているオープンソースの脆弱性スキャナ

‣ 外部の脆弱性データベース (例: CVE) から収集したデータを PostgreSQL に格納するとともに、
 
イメージ内に含まれるパッケージ等の脆弱性を検出する

Trivy (https://github.com/aquasecurity/trivy)

‣ Aqua Security からリリースされているオープンソースの脆弱性スキャナ

‣ Clair と同様に脆弱性データベースの情報をもとにイメージ内のパッケージ等の脆弱性を検出するが、
 
シングルバイナリで動作するため、CI (自動テスト) に組み込みやすい長所を持つ
コンテナイメージ向けの脆弱性スキャナ
CVE-XXXX-YYYY

Package hoge (< v1.5)
脆弱性データベース
︙
Package hoge (v1.4)
コンテナイメージ
︙
CVE-XXXX-YYYY

View Slide

コンテナにおける脅威: コンテナイメージの改ざん

‣ 概要

- コンテナレジストリに登録されている
 
コンテナイメージが不正に改ざんされている恐れがある

‣ 対策

- 信頼できるコンテナイメージのみを保有する
 
プライベートレジストリを構築する

- イメージを指定する際にダイジェストを指定する

- Docker Content Trust 等を用いてイメージに対して署名を付与する
59
コンテナにおける脅威: コンテナイメージの改ざん

View Slide

コンテナにおける脅威: 機密情報が埋め込まれたコンテナイメージ

‣ 概要

- コンテナイメージ内にパスワードや秘密鍵、アクセストークン等の
 
機密情報が埋め込まれている場合、
 
それを解析されると機密情報が流出する

- Docker コンテナはビルドの各ステップごとに
 
新たなイメージレイヤを作成するため、
 
途中のステップで削除しても復元可能

‣ 対策

- 実行時にのみ必要な機密情報は環境変数やファイルシステムのマウント等で対応する

- マルチステージビルドを利用し、機密情報を必要とするビルドプロセスを分離する

- ビルド中にネットワーク経由で取得する
60
コンテナにおける脅威: 機密情報が埋め込まれたコンテナイメージ

View Slide

コンテナにおける脅威: コンテナブレイクアウト

‣ 概要

- コンテナおよびそのランタイム等に存在する脆弱性や
 
設定不備を利用してコンテナの隔離環境をエスケープし、
 
ホスト側のリソースにアクセスすること

- 現在主流のコンテナランタイムである runc には、
 
過去にコンテナブレイクアウトを可能にする
 
脆弱性が存在した (CVE-2019-5736)
 
- 特権コンテナや多くの Capability を有するコンテナは
 
当該脆弱性のリスクが高まる

‣ 対策

- コンテナの実行ユーザや実行グループを root 以外に指定する

- 不要な Capability をコンテナに与えない (例: --cap-drop all オプションを指定した上で必要なものだけ --cap-add する)

- セキュリティを意識して実装されたランタイムを利用する (例: gVisor, Kata Containers)
61
コンテナにおける脅威: コンテナブレイクアウト
ホスト OS

View Slide

gVisor

‣ 参照: https://github.com/google/gvisor

‣ アプリケーションによって発行されたシステムコールをフックし、
 
ユーザランドで稼働する Sentry がシステムコールの発行や
 
ファイルアクセスを代行する

‣ Sentry からホストのカーネルに対するシステムコールの
 
呼び出しは一部のものに限定される

- そのため、現時点では互換性が担保されない場合がある

Kata Containers

‣ 参照: https://katacontainers.io/

‣ コンテナごとに軽量な VM (micro VM) を起動し、
 
その中でコンテナを動作させる

‣ 仮想化支援機能 (例: Intel VT-x) が利用できる
 
環境でのみ動作する
セキュアなランタイムの例: gVisor, Kata Containers
https://gvisor.dev/blog/2019/11/18/gvisor-security-basics-part-1/ より引用

View Slide

リクエストの検証

‣ 認証認可のチェック、リクエストのバリデーションを行うことで
 
クラスタに不正なリソースがデプロイされることを事前に防止する

- 例: 権限を持たない主体によるリクエスト、リソースを大量に消費するワークロードをデプロイするリクエスト
 
特権コンテナや権限昇格が可能なコンテナをデプロイするリクエスト

クラスタのハードニング

‣ オーケストレータ内のコンポーネント間の通信に TLS を用いる

‣ 秘匿性の高いデータを適切に扱う

- 例: 機密データの保持に特化したデータストアの利用、データストアの暗号化

クラスタを構成するホストのハードニング

‣ 不要な機能やライブラリを含まない OS を利用する (例: Container-Optimized OS)

- cf. Limiting the Attack Surface
コンテナオーケストレータのセキュリティの概要

View Slide

Kubernetes におけるリクエストの検証

‣ Kubernetes クラスタに対するすべてのリクエストは API Server が受け付ける

‣ API Server では認証や認可のチェックに加えて Admission Control と呼ばれるリクエストの制御を行う
Kubernetes におけるリクエストの検証
Authentication
Authorization
Mutating Admission
Object Schema Validation
Validating Admission
etcd
リクエスト
API Server
… サービスアカウントトークンや OIDC による認証を行う
… (主に) RBAC による権限のチェックを行う
… 定義されたポリシーに基づいてリクエストを改変する
… リクエストのバリデーション (フォーマットのチェック) を行う
… 定義されたポリシーに基づいてリクエストを許可するかどうか判定する

View Slide

認可

‣ あるリソースに対するアクセス権限の制御を行う仕組み

‣ 権限 = 誰が、何に、どのような操作を実行してよいのか (よくないのか)

‣ Kubernetes は現在 RBAC による認可が推奨されている

RBAC (Role-Based Access Control)

‣ アクセスを行う主体にロールを割り当て、そのロールごとに権限を付与する

‣ Kubernetes では下の表に示すロールがデフォルトで定義されている
Kubernetes における RBAC による認可
ロール名概要
cluster-admin クラスタ内のすべてのリソースに対する任意の権限を有する
admin ResourceQuota 等の一部のリソースを除いたほぼすべてのリソースに対する権限を有する
edit 権限関連のリソース以外に対する読み取りおよび書き込みの権限を有する
view 権限関連および秘密情報のリソース以外に対する読み取り権限を有する
Role R
Pod: 取得、作成、更新、削除

Service: 取得

View Slide

PodSecurityPolicy

‣ リクエストされた Pod のセキュリティ関連の設定を確認し、
 
ポリシーに反する場合はリクエストを拒否する

‣ Kubernetes v1.21 において deprecated (非推奨) となった

- 現在は PodSecurity や Gatekeeper (後述) への過渡期

LimitRanger

‣ リクエストされた Pod に含まれるコンテナの
 
リソース量指定の最小値や最大値等を強制する

ResourceQuota

‣ Namespace (クラスタを論理的に分割したもの) ごとに
 
利用できるリソース量やリソースの個数の上限値を定義できる
Admission Control の例
apiVersion: policy/v1beta1

kind: PodSecurityPolicy

spec:

privileged: false
YAML
apiVersion: v1

kind: LimitRange

namespace: foobar

spec:

limits:

- type: Container

max:

cpu: 10
YAML
apiVersion: v1

kind: ResourceQuota

spec:

hard:

cound/pods: 10
YAML

View Slide

Open Policy Agent

‣ ポリシー記述用の言語 (Rego) やポリシーをもとにリクエストを評価するエンジン、
 
リクエストを送るための API 等を提供している

‣ Policy as Code (ポリシーのコード化) を実現するエコシステムの一種

Kubernetes における Open Policy Agent の利用例

‣ Conftest (https://github.com/open-policy-agent/conftest)

- マニフェストに対する静的なユニットテストを実行できるツール

- 定義されたポリシーに反するマニフェストがあればテストに失敗する

‣ Gatekeeper (https://github.com/open-policy-agent/gatekeeper)

- API Server の Admission Controller として動作する

- リクエストをフックし、定義されたポリシーに反するリクエストがあれば破棄する

‣ Conftest によるマニフェストの事前チェックと Gatekeeper によるリクエストの最終チェックを
 
組み合わせて用いると有用
Open Policy Agent を用いたマニフェストとリクエストの検査

View Slide

コンポーネント間の通信

‣ オーケストレータ内では様々なコンポーネントが相互に通信している

- 例: kubelet と API Server 間, Controller Manager と API Server 間等

‣ コンポーネント間の通信においは、以下の要件が担保されている必要がある

- 通信が暗号化されていること (秘密情報がやりとりされることがあるため)

- 通信の相手が意図した相手である (= なりすましではない) こと

mTLS (mutual-TLS) による通信の暗号化とクライアント認証

‣ TLS を用いて相互に認証を行う仕組み

- 一般的に Web ブラウザと Web サーバ間の通信で利用される TLS (HTTPS) はサーバの認証のみ
コンポーネント間通信の mTLS 化
コンポーネントコンポーネントクライアントサーバ
検証
検証
検証

View Slide

攻撃者視点から考える: Kubernetes の脅威マトリックス
Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Impact
Threat Matrix for Kubernetes

‣ MITRE ATT&CK Framework をベースに作成された
 
Kubernetes に対する脅威マトリックス

‣ Kubernetes に対する攻撃の手順や攻撃のテクニックが記載されている

‣ 右図に示す 10 の戦術 (Tactics) が定義されている

‣ 参照: https://www.microsoft.com/security/blog/2020/04/02/attack-
matrix-kubernetes/

‣ 参照: https://www.microsoft.com/security/blog/2021/03/23/secure-
containerized-environments-with-updated-threat-matrix-for-kubernetes/

View Slide

Initial Access
Execution
Persistence
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Impact
Kubernetes クラスタにアクセスするための取っ掛かりを得る

• クラスタにアクセスするためのクレデンシャルを奪取する
Initial Access
Kubernetes クラスタで不正なアクションを実行する

• kubectl exec コマンドを利用して既存のコンテナ上で不正なコマンドを実行する
Execution
クラスタへのアクセスを維持する

• 不正な (例: バックドアが存在する) コンテナをクラスタにデプロイさせる
Persistence
より影響度の高い攻撃を実行するために強力な権限を取得する

• 特権コンテナを実行する

View Slide

Initial Access
Execution
Persistence
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Impact
攻撃の兆候が検出されることを回避する

• コンテナが出力するログや Kubernetes のイベントログを削除する
Defense Evasion
クラスタ内に存在する機密性の高い情報を取得する

• 機密情報が記載された Secret リソースを取得する
Credential Access
攻撃対象を探索する

• Kubernetes Dashboard にアクセスする
Discovery
最初に侵入したコンテナやノード以外のリソースに侵入を拡げる

• DNS Poisoning や ARP Poisoning によって他のワークロードのトラフィックを盗聴する
Lateral Movement

View Slide

Initial Access
Execution
Persistence
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Impact
クラスタからデータを収集する

• プライベートレジストリからコンテナイメージを取得する
Collection
クラスタを破壊・悪用・混乱させる

• クラスタにデプロイされたリソースを不正に削除する

• クラスタのリソースを不正に消費する (クリプトマイニングを行うコンテナ等)
Impact

View Slide


セキュリティの実践
脆弱性が存在するコンテナがデプロイされることを防止するための仕組みを実践します。
また、ポリシーに反するワークロードがデプロイされることを防止するための仕組みを構
築します。
Part 4

View Slide

コンテナとその実行基盤を取り巻くセキュリティの実践
本パートのハンズオンで実施すること
脆弱性スキャナの実践

‣ 脆弱性スキャナを利用したコンテナイメージの脆弱性スキャンの実行

‣ 検出した脆弱性のレポート化、ケーススタディ

Open Policy Agent / Gatekeeper による Policy as Code の実践

‣ 特権コンテナのリクエストを破棄するポリシーの実装と動作確認

View Slide

ハンズオン: 脆弱性スキャナの実行

‣ ex3_vuln_scanner ディレクトリ内のデータを利用します

‣ Trivy を用いて好きなコンテナイメージの脆弱性スキャンを行ってください

- コンテナイメージは Docker Hub (https://hub.docker.com/) にて検索できます

- 意図的に過去のバージョンを指定するとより脆弱性が見つかりやすいかもしれません
ハンズオン: 脆弱性スキャナの実行
# cd ex3_vuln_scanner
Bash
# trivy image <イメージ名>
Bash

View Slide

ハンズオン: 脆弱性スキャナの実行と考察

‣ 先ほどのハンズオンで脆弱性が検出されたコンテナイメージを 1 つピックアップしてください

‣ 当該コンテナイメージから検出された脆弱性のうち、気になったものを 1 つピックアップしてください

‣ 同ディレクトリ内の memo.md を利用して、以下の事項に回答してください

- 選択したコンテナイメージ

- 実行結果

- CVE ID

- 脆弱性が存在するライブラリ

- 脆弱性の概要 (例: ... に不備があるため、... を実行することが可能である)

- 対応方法

「対応方法」に記述してほしいこと

‣ あなたはある会社の情報セキュリティの担当者です

‣ 同僚の開発者が「利用したいコンテナイメージに (上で選択した) 脆弱性が存在するみたいなのですが、
 
どうすればいいですか？」と聞いてきました

‣ 開発者は早くプロダクトをリリースしたいので、可能な限りそのコンテナイメージを使いたいと考えています

‣ あなたはどのように対応しますか？
ハンズオン: 脆弱性スキャナの実行と対応方法の考察

View Slide

Open Policy Agent

‣ ポリシー記述用の言語 (Rego) やポリシーをもとにリクエストを評価するエンジン、
 
リクエストを送るための API 等を提供している

‣ Policy as Code (ポリシーのコード化) を実現するエコシステムの一種

Kubernetes における Open Policy Agent の利用例

‣ Conftest (https://github.com/open-policy-agent/conftest)

- マニフェストに対する静的なユニットテストを実行できるツール

- 定義されたポリシーに反するマニフェストがあればテストに失敗する

‣ Gatekeeper (https://github.com/open-policy-agent/gatekeeper)

- API Server の Admission Controller として動作する

- リクエストをフックし、定義されたポリシーに反するリクエストがあれば破棄する

‣ Conftest によるマニフェストの事前チェックと Gatekeeper によるリクエストの最終チェックを
 
組み合わせて用いると有用
(再掲) Open Policy Agent を用いたマニフェストとリクエストの検査

View Slide

ハンズオン: Gatekeeper のデプロイ

‣ ex4_gatekeeper ディレクトリ内のデータを利用します

‣ スクリプトを実行して Gatekeeper 関連のリソースをクラスタにデプロイしてください
ハンズオン: Gatekeeper のデプロイ
# cd ex4_gatekeeper
Bash
# ./install-gatekeeper.sh
Bash

View Slide

Gatekeeper 関連のリソース (CRD; Custom Resource De
fi
nition)

‣ 制約テンプレート ... Rego で記述されたポリシーを定義するリソース

‣ 制約 ... 制約テンプレートを適用する箇所を定義するリソース
Gatekeeper 関連のリソース
特権コンテナの利用を禁止するポリシー
制約テンプレートの例
ポリシーを Pod のリクエストに対して適用する
制約の例
https://kubernetes.io/blog/2019/08/06/opa-gatekeeper-
policy-and-governance-for-kubernetes/より引用

View Slide

パッケージの宣言

変数の束縛
Rego の基礎 (1)
package example
Rego
one := 1

numbers := {

"one": 1,

"two": 2,

"three": 3

}
Rego

View Slide

ルール

‣ ブロック内のすべての条件が true と評価される場合が存在すれば true と評価され、
 
そうではない場合は unde
fi
ned と評価される
Rego の基礎 (2)
this_is_true {

1 == 1

2 == 2

}

this_is_undefined {

1 == 1

2 == 3

}
Rego

View Slide

集合を返すルール

‣ ルール名の後ろに [値] を付与すれば、ブロック内の条件が true と評価される場合に対応する値の集合を
 
評価結果とすることができる
Rego の基礎 (2)
books := [

{ "title": "seccamp book", "year": 2021 },

{ "title": "minicamp book", "year": 2020 },

{ "title": "rego book", "year": 2019, }

]

published_after_2020_titles[book.title] {

book := books[_]

book.year >= 2020

}

# 評価結果

# {

# "published_after_2020_titles": [

# "minicamp book",

# "seccamp book"

# ]

# }
Rego

View Slide

制約テンプレートの実装方法

‣ ConstraintTemplate リソースとして定義する

‣ リクエストされたマニフェストは input.review.object で参照可能

‣ violation ルールが値を返す場合 (undefined ではない場合) にリクエストが拒否される
制約テンプレートの実装方法
package example

# Pod の .spec.containers からコンテナを 1 つ取り出す

c := input.review.object.spec.containers[_]
Rego
package example

violation[{"msg": msg}] {

msg := "常にリクエストを拒否する"

}
Rego
apiVersion: v1

kind: Pod

metadata:

name: nginx-pod

spec:

containers:


image: nginx:1.21
Pod (参考)

View Slide

特権コンテナを拒否する制約テンプレートの実装

‣ constrainttemplate.yaml を開いてください

‣ Rego を用いてコンテナの Security Context に privileged: true が設定されている場合に、
 
「Privileged container detected: <コンテナの名前>」を出力してリクエストを破棄するルールを記述してください
ハンズオン: 特権コンテナを拒否する制約テンプレートの実装
package privilegedcontainerconstraint


# 以下に記述してください

...

}
Rego

View Slide

制約テンプレートと制約のデプロイ

‣ 以下のコマンドを実行して制約テンプレートと制約をデプロイしてください

‣ 特権コンテナを含まない Pod が定義された allow.yaml を正常にデプロイできることを確認してください

‣ 特権コンテナを含む Pod が定義された disallow.yaml のリクエストが破棄されることを確認してください
ハンズオン: 制約テンプレートと制約のデプロイ、動作検証
# kubectl apply -f constrainttemplate.yaml

# kubectl apply -f constraint.yaml
Bash
# kubectl apply -f allow.yaml
Bash
# kubectl apply -f disallow.yaml
Bash

View Slide

特権コンテナを拒否する制約の確認
ハンズオン: 特権コンテナを拒否する制約の確認
# cat allow.yaml

apiVersion: v1

kind: Pod

metadata:

name: unprivileged-nginx-pod

spec:

containers:


image: nginx:1.21

securityContext:

privileged: false

# kubectl apply -f allow.yaml

pod/unprivileged-nginx-pod created
Bash
# cat disallow.yaml

apiVersion: v1

kind: Pod

metadata:

name: privileged-nginx-pod

spec:

containers:


image: nginx:1.21

securityContext:

privileged: true

# k apply -f disallow.yaml

Error from server ([privileged-container-constraint] Privileged
container detected: nginx-container): error when creating
"disallow.yaml": admission webhook "validation.gatekeeper.sh"
denied the request: [privileged-container-constraint] Privileged
container detected: nginx-container
Bash

View Slide

特権コンテナを拒否する制約テンプレートの実装

‣ constrainttemplate.yaml を開いてください

‣ Rego を用いてコンテナの Security Context に privileged: true が設定されている場合に、
 
「Privileged container detected: <コンテナの名前>」を出力してリクエストを破棄するルールを記述してください
ハンズオン: 特権コンテナを拒否する制約テンプレートの実装
package privilegedcontainerconstraint


# 以下に記述してください

c := input.review.object.spec.containers[_]

c.securityContext.privileged

msg := sprintf("Privileged container detected: %v", [c.name])

}
Rego

View Slide

まとめ: 脆弱性スキャナ

‣ 脆弱性スキャナを用いることでコンテナイメージ内の脆弱性を検出することができる

‣ 自動テスト等に組み込むことで、事前に脆弱性を含んだコンテナがデプロイされることを防止できる

まとめ: Gatekeeper

‣ Gatekeeper を用いることでデプロイ時にリクエストの内容を検証できる

‣ 検証のためのポリシーをコードとして表現することができる (Policy as Code)

今後の方針

‣ 脆弱性スキャナを CI に組み込んで、脆弱性が存在する場合にデプロイやマージを防ぐ仕組みを構築する

‣ Open Policy Agent を用いて、その他のポリシーをコード化してみる

- 例: 実行ユーザが root のコンテナを拒否する、イメージ名にダイジェストが指定されていないコンテナを拒否する
ハンズオンのまとめと今後の方針

View Slide

おわりに
本日の講義内容を総括するとともに、今後の学習に向けた指針を提示します。
Part 5

View Slide

コンテナとコンテナオーケストレーションの技術的な原理を理解し、説明できる

コンテナを用いたシステムのデプロイ手法を実践できる

コンテナとその実行基盤を取り巻くセキュリティ上の脅威を理解し、説明できる

コンテナとその実行基盤を取り巻くセキュリティ上の脅威を緩和するための仕組みを実践できる
おわりに
再掲: 本講義の目標
複雑かつ非常に速いスピードで進化を続ける今日のコンテナ関連技術と

そのセキュリティにキャッチアップするための素養を身に付ける
本講義の目標

View Slide

Part 1: コンテナとコンテナオーケストレーションの基礎

‣ コンテナ型仮想化技術を構成する技術要素を説明します

‣ コンテナ型仮想化およびコンテナ実行基盤のデファクトスタンダードである Docker, Kubernetes の概要を説明します

Part 2: コンテナを用いたシステムのデプロイ

‣ Docker および Kubernetes を用いたコンテナによるシステム (Web サーバ) のデプロイを実践します

Part 3: コンテナとその実行基盤を取り巻くセキュリティの基礎

‣ コンテナオーケストレーション環境の各構成要素に存在するセキュリティ上の脅威を分類し、説明します

Part 4: コンテナとその実行基盤を取り巻くセキュリティの実践

‣ 脆弱性が存在するコンテナがデプロイされることを防止するための仕組みを実践します

‣ ポリシーに反するワークロードがデプロイされることを防止するための仕組みを構築します

Part 5: おわりに

‣ 本日の講義内容を総括するとともに、今後の学習に向けた指針を提示します
おわりに
再掲: 本日の講義の流れ

View Slide

Cloud Native Trail Map

‣ Cloud Native Computing Foundation が公表している
 
Cloud Native 技術のロードマップ

‣ 今回は触れなかった Cloud Native 関連の
 
トピックが網羅されている

- Observability & Analysis

- Service Mesh

- Networking (Container Network Interface)

- Distributed Database

- Messaging (gRPC)
おわりに
Cloud Native Trail Map

View Slide

Cloud Native Landscape (https://landscape.cncf.io/)

‣ 主に Cloud Native Computing Foundation がホストしている Cloud Native 関連のプロジェクトの一覧

‣ 興味がある OSS を見つけてデプロイしたり、実装を読んだり、コントリビュートしたりしてみると勉強になります
おわりに
Cloud Native Landscape

View Slide

おわりに
参考文献
川口直也, コンテナ型仮想化概論, カットシステム, 2020.

Sean P. Kane, Karl Matthias, Docker: Up & Running: Shipping Reliable Containers in Production 2nd Edition, O'Reilly, 2018.

Kelsey Hightower, Brendan Burns, Joe Beda: Kubernetes: Up and Running, O'Reilly, 2017.

阿佐志保, 真壁徹: しくみがわかるKubernetes Azureで動かしながら学ぶコンセプトと実践知識, 翔泳社, 2019.

青山真也: Kubernetes完全ガイド第2版, インプレス, 2020.

早川博, 北山晋吾: Kubernetes実践ガイドクラウドネイティブアプリケーションを支える技術, インプレス, 2019.

須田瑛大, 五十嵐綾, 宇佐美友也: Docker/Kubernetes開発・運用のためのセキュリティ実践ガイド, マイナビ出版, 2020.

澤橋松王, 岩上隆志, 小林弘典, 小幡学, 関克隆: クラウドネイティブセキュリティ入門, シーアンドアール研究所, 2021.

John Arundel, Justin Domingus: Cloud Native DevOps with Kubernetes, O'Reilly, 2019.

Liz Rice: Container Security: Fundamental Technology Concepts that Protect Containerized Applications, O'Reilly, 2020.

Liz Rice, Michael Hausenblas: Kubernetes Security, O'Reilly, 2018.

Amit Gupta, Brendan Creane: Kubernetes Security and Observability: A Holistic Approach to Securing Containers and Cloud
Native Applications, 2021.

mrtc0: Container Security Book, https://container-security.dev/

Kaizhe Huang, Pranjal Jumde: Learn Kubernetes Security, Packt, 2020.

NIST: Special Publication 800-190 Application Container Security Guide, https://nvlpubs.nist.gov/nistpubs/specialpublications/
nist.sp.800-190.pdf.

NSA: Kubernetes Hardening Guidance, https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/
CTR_KUBERNETESHARDENINGGUIDANCE.PDF.

View Slide

おわりに
講義資料内で触れたソフトウェア等のリンク
Docker (https://www.docker.com/)

Kubernetes (https://kubernetes.io/)

Containerd (https://containerd.io/)

runc (https://github.com/opencontainers/runc)

gVisor (https://gvisor.dev/)

Kata Containers (https://katacontainers.io/)

Trivy (https://github.com/aquasecurity/trivy)

Clair (https://github.com/quay/clair)

Open Policy Agent (https://www.openpolicyagent.org/)

Gatekeeper (https://github.com/open-policy-agent/gatekeeper)

Conftest (https://www.conftest.dev/)

View Slide

おわりに
利用したアイコン画像
fl
aticon (https://www.
fl
aticon.com/)

View Slide

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプオンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプオンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure

Tsubasa

More Decks by Tsubasa

Other Decks in Technology

Featured

Transcript

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプ オンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプ オンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure

Tsubasa

More Decks by Tsubasa

Other Decks in Technology

Featured

Transcript

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプオンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure

コンテナとその実行基盤を取り巻くセキュリティの基礎と実践 (セキュリティ・ミニキャンプオンライン 2021 講義資料) / Fundamentals and Practices of Security around Containers and their Execution Infrastructure