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
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
nezumisannn
May 25, 2019
Technology
0
470
20190525_GCPUG_KYOTO_登壇資料.pdf
nezumisannn
May 25, 2019
Tweet
Share
More Decks by nezumisannn
See All by nezumisannn
20250930_Conohaウェビナー_生成AI_Terraform_ConoHa_VPSサーバー_セットアップ入門編
nezumisannn
1
26
20250723_Conohaウェビナー_高騰する海外クラウド費用を劇的カット_サーバーコスト最適化のポイント解説と成功事例のご紹介.pdf
nezumisannn
0
38
20241204_ビヨンド勉強会_44_AWS_Service_Catalogを利用したIaCのテンプレート化とTerraformによるデプロイ.pdf
nezumisannn
0
330
20240828_ビヨンド勉強会_42_EKS_on_FargateでWebサービスを公開するために覚えておきたいこと.pdf
nezumisannn
0
98
20240530_ビヨンド勉強会#41_ビヨンドのエンジニア新卒研修における取り組み
nezumisannn
0
130
20230511_AWSにおけるコンテナサービスの選択とIaC実装例.pdf
nezumisannn
0
1.3k
リーダーになって1年経過して_取り組んできたことと大事にしている考え方_の裏側_.pdf
nezumisannn
0
82
20211118_GKEにおける高負荷時のPodとWorker_Nodeの挙動について.pdf
nezumisannn
0
170
20211014_Alibaba_Cloud_Container_Service_for_KubernetesにおけるServerless_Kubernetesの概要とManaged_Kubernetesとの違い.pdf
nezumisannn
0
100
Other Decks in Technology
See All in Technology
Red Hat OpenStack Services on OpenShift
tamemiya
0
140
量子クラウドサービスの裏側 〜Deep Dive into OQTOPUS〜
oqtopus
0
150
Why Organizations Fail: ノーベル経済学賞「国家はなぜ衰退するのか」から考えるアジャイル組織論
kawaguti
PRO
1
210
Agent Skils
dip_tech
PRO
0
140
AzureでのIaC - Bicep? Terraform? それ早く言ってよ会議
torumakabe
1
610
私たち準委任PdEは2つのプロダクトに挑戦する ~ソフトウェア、開発支援という”二重”のプロダクトエンジニアリングの実践~ / 20260212 Naoki Takahashi
shift_evolve
PRO
2
210
OpenShiftでllm-dを動かそう!
jpishikawa
0
140
SchooでVue.js/Nuxtを技術選定している理由
yamanoku
3
210
Codex 5.3 と Opus 4.6 にコーポレートサイトを作らせてみた / Codex 5.3 vs Opus 4.6
ama_ch
0
220
配列に見る bash と zsh の違い
kazzpapa3
3
170
コミュニティが変えるキャリアの地平線:コロナ禍新卒入社のエンジニアがAWSコミュニティで見つけた成長の羅針盤
kentosuzuki
0
130
Embedded SREの終わりを設計する 「なんとなく」から計画的な自立支援へ
sansantech
PRO
3
2.6k
Featured
See All Featured
BBQ
matthewcrist
89
10k
Embracing the Ebb and Flow
colly
88
5k
How STYLIGHT went responsive
nonsquared
100
6k
The agentic SEO stack - context over prompts
schlessera
0
650
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
130
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
140
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
62
50k
How to Think Like a Performance Engineer
csswizardry
28
2.5k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.3k
Building AI with AI
inesmontani
PRO
1
710
How GitHub (no longer) Works
holman
316
140k
Producing Creativity
orderedlist
PRO
348
40k
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