Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20190525_GCPUG_KYOTO_登壇資料.pdf
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
nezumisannn
May 25, 2019
Technology
480
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
20190525_GCPUG_KYOTO_登壇資料.pdf
nezumisannn
May 25, 2019
More Decks by nezumisannn
See All by nezumisannn
20250930_Conohaウェビナー_生成AI_Terraform_ConoHa_VPSサーバー_セットアップ入門編
nezumisannn
1
37
20250723_Conohaウェビナー_高騰する海外クラウド費用を劇的カット_サーバーコスト最適化のポイント解説と成功事例のご紹介.pdf
nezumisannn
0
55
20241204_ビヨンド勉強会_44_AWS_Service_Catalogを利用したIaCのテンプレート化とTerraformによるデプロイ.pdf
nezumisannn
0
390
20240828_ビヨンド勉強会_42_EKS_on_FargateでWebサービスを公開するために覚えておきたいこと.pdf
nezumisannn
0
110
20240530_ビヨンド勉強会#41_ビヨンドのエンジニア新卒研修における取り組み
nezumisannn
0
140
20230511_AWSにおけるコンテナサービスの選択とIaC実装例.pdf
nezumisannn
0
1.4k
リーダーになって1年経過して_取り組んできたことと大事にしている考え方_の裏側_.pdf
nezumisannn
0
92
20211118_GKEにおける高負荷時のPodとWorker_Nodeの挙動について.pdf
nezumisannn
0
180
20211014_Alibaba_Cloud_Container_Service_for_KubernetesにおけるServerless_Kubernetesの概要とManaged_Kubernetesとの違い.pdf
nezumisannn
0
110
Other Decks in Technology
See All in Technology
AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界
sansantech
PRO
3
1.1k
脱金融のフューチャー・デザイン / Future Design Beyond Finance
ks91
PRO
0
160
マルチアカウント環境でSecurity Hubの運用、その後どうなった? / SRE NEXT 2026 miniLT会
genda
0
110
Kaggleで成長するために意識したこと
prgckwb
2
420
第67回コンピュータビジョン勉強会CVPR2026読会前編
tsukamotokenji
0
160
ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略
srenext
0
890
仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える / AICon2026_hirakawa
rakus_dev
0
200
AIコード生成×サプライチェーン攻撃 — PHPが直面する“二重の信頼問題
shinyasaita
0
240
しくみを学んで使いこなそう GitHub Copilot app
torumakabe
2
290
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
670
ガバナンスの「ちょうどいい落とし所」を探れ!開発スピードを妨げない運用判断の勘所 / SRE NEXT 2026
genda
1
260
世界、断片、モデル。そして理解
ardbeg1958
1
130
Featured
See All Featured
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
190
So, you think you're a good person
axbom
PRO
2
2.1k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
67k
Documentation Writing (for coders)
carmenintech
77
5.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.4k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.6k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.1k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
260
Side Projects
sachag
455
43k
For a Future-Friendly Web
brad_frost
183
10k
Speed Design
sergeychernyshev
33
1.9k
Building an army of robots
kneath
306
46k
Transcript
GKE + Vuls コンテナを用いた 脆弱性診断サーバ
はじめに ▸ 普段は熱烈なA◦◦信者です ▸ 数週間前までKubernetes is 何状態でした ▸ 今回はGKEをちゃんと利用しました ▸
生温かい目で見守っていただけると幸いです 2
ねずみさん家。 Yuki.Teraoka@yktr_sre 株式会社ビヨンド システムソリューション部 SREチーム SRE4年目 サーバのことを全部丸投げされる人 3
アジェンダ ▸ そもそも脆弱性って? ▸ 脆弱性との戦い ▸ 脆弱性対応の効率化 ▸ GKE for
Vuls ▸ 使用ツールと仕組みの解説 4
脆弱性って? ▸ コンピュータソフトウェアの欠陥 ▸ セキュリティホールと呼ばれる ▹ 本来操作できないはずの操作が出来る ▹ 見えるべきではない情報が見える ▸
攻撃されるとたちまち悪影響が ▹ 秘匿情報の外部への漏洩 ▹ システムの乗っ取り、破壊 5
脆弱性との戦い ▸ 脆弱性に対しては対策を打たなければならない ▹ 脆弱性情報の取得 ▹ 緊急性/影響範囲の把握 ▹ 修正パッチリリース情報の取得 ▹
パッチの適用 6
脆弱性との戦い ▸ 都度対策したとしても。。。 ▹ 脆弱性自体は0にならない ▹ 対策した直後にまた新たな脆弱性 ▹ 正直いたちごっこ ▹
それでも放置できないというジレンマ ▹ どげんかせんといかん 7
脆弱性対応の効率化 ▸ 問題点を洗い出してみると ▹ 監視対象のサーバが増えると追いきれない ▹ 種類ごとの緊急度が把握できない ▹ 影響を受ける環境を把握するのが難しい 8
脆弱性対応の効率化 ▸ 理想としては ▹ サーバが増えても情報を把握できる ▹ 緊急度に応じて対応の要否や対応までの時間を 決定できる ▹ サーバごとに該当する脆弱性がどれかわかる
▹ 定期的に自動で脆弱性診断が行える ▸ 手作業では厳しいので仕組みを考える必要がある 9
GKE for Vuls ▸ 仕組みを考えました( ▹ インフラにGoogle Kubernetes Engineを採用 ▹
Vulsを使って定期的リモートスキャン ▹ スキャンした結果をチャットに通知 10
使用ツールと仕組みの解説 ▸ Vulsとは ▹ Linux/FreeBSD向けの脆弱性スキャンツール ▹ OSSであり、Golangで開発されている ▹ エージェントレスで導入が簡単 ▹
スキャン結果をSlackなどに通知できる 11
使用ツールと仕組みの解説 ▸ Vulsは公式のDocker Imageが用意されている ▸ go-cve-dictionary ▹ docker pull vuls/go-cve-dictionary
▸ goval-dictionary ▹ docker pull vuls/goval-doctionary ▸ gost ▹ docker pull vuls/gost ▸ vuls ▹ docker pull vuls/vuls 12
使用ツールと仕組みの解説 ▸ Docker ImageはGCRで管理する ▸ go-cve-dictionary ▹ docker push gcr.io/[prj
id]/vuls/go-cve-dictionary ▸ goval-dictionary ▹ docker push gcr.io/[prj id]/vuls/goval-dictionary ▸ gost ▹ docker push gcr.io/[prj id]/vuls/gost ▸ vuls ▹ docker push gcr.io/[prj id]/vuls/vuls 13
使用ツールと仕組みの解説 ▸ GCPに構築しているリソースは以下の通り ▹ google_compute_network ▹ google_compute_subnetwork ▹ google_compute_router ▹
google_compute_address ▹ google_compute_router_nat ▹ google_container_cluster ▹ google_container_node_pool 14
使用ツールと仕組みの解説 ▸ 特徴 ▹ PodのIPを固定するためCloud NATを利用 ▹ そのため限定公開クラスタになっている ▹ Nodeはプリエンプティブインスタンスで起動
▹ リソースは全てTerraformでコード化 15
使用ツールと仕組みの解説 16
使用ツールと仕組みの解説 17
使用ツールと仕組みの解説 18
使用ツールと仕組みの解説 19
使用ツールと仕組みの解説 20
使用ツールと仕組みの解説 21
使用ツールと仕組みの解説 22
使用ツールと仕組みの解説 ▸ Kubernetesのリソースは以下の通り ▹ PersistentVolumeClaim ▹ ConfigMap ▹ Secret ▹
kubectl create secret generic vuls-scan-key --from-file=id_rsa=[path/to/secret/key/file] ▹ Job ▹ CronJob 23
使用ツールと仕組みの解説 ▸ 特徴 ▹ Vulsがスキャン時に利用するデータベース用に PersistentVolumeClaimで永続ボリュームを作成 ▹ ConfigMapで必要な設定ファイルを管理 ▹ vulsの設定ファイル(config.toml)
▹ SSHのconfigファイル 24
使用ツールと仕組みの解説 ▸ 特徴 ▹ SSH接続に必要な秘密鍵はyamlでは管理しない ▹ Secretリソースを利用している ▹ Jobでスキャンで使う脆弱性データベースを取得 ▹
CronJobで定期スキャンと結果の送信を行う 25
使用ツールと仕組みの解説 26
使用ツールと仕組みの解説 27
使用ツールと仕組みの解説 28
使用ツールと仕組みの解説 29
使用ツールと仕組みの解説 30
使用ツールと仕組みの解説 31
使用ツールと仕組みの解説 32
使用ツールと仕組みの解説 33
使用ツールと仕組みの解説 34
使用ツールと仕組みの解説 35
使用ツールと仕組みの解説 36
使用ツールと仕組みの解説 37 ▸ 後はひたすらyamlの内容を反映 ▹ kubectl apply -f configmap_ssh_config.yaml ▹
kubectl apply -f job_fetch_jvn.yaml ▹ kubectl apply -f job_fetch_oval_redhat.yaml ▹ kubectl apply -f job_fetch_gost_redhat.yaml ▹ etc… ▹ 作成したyamlとTerraformのコードは後日githubに アップロードするので良ければ見てみてください!
使用ツールと仕組みの解説 38
まとめ 39 ▸ 脆弱性は0にならないけど見逃せない ▸ 少しでも効率化したいのでこの仕組みを作った ▸ Kubernetesを使っていると案の定yaml地獄に ▹ helmを使うとなお管理しやすくなるかも
▸ 気になった方は是非試してみてください! ▸ 皆様の脆弱性対応のお供になると幸いです
Thank you for listening! 40