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
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
11
20250723_Conohaウェビナー_高騰する海外クラウド費用を劇的カット_サーバーコスト最適化のポイント解説と成功事例のご紹介.pdf
nezumisannn
0
27
20241204_ビヨンド勉強会_44_AWS_Service_Catalogを利用したIaCのテンプレート化とTerraformによるデプロイ.pdf
nezumisannn
0
280
20240828_ビヨンド勉強会_42_EKS_on_FargateでWebサービスを公開するために覚えておきたいこと.pdf
nezumisannn
0
88
20240530_ビヨンド勉強会#41_ビヨンドのエンジニア新卒研修における取り組み
nezumisannn
0
120
20230511_AWSにおけるコンテナサービスの選択とIaC実装例.pdf
nezumisannn
0
1.3k
リーダーになって1年経過して_取り組んできたことと大事にしている考え方_の裏側_.pdf
nezumisannn
0
66
20211118_GKEにおける高負荷時のPodとWorker_Nodeの挙動について.pdf
nezumisannn
0
150
20211014_Alibaba_Cloud_Container_Service_for_KubernetesにおけるServerless_Kubernetesの概要とManaged_Kubernetesとの違い.pdf
nezumisannn
0
83
Other Decks in Technology
See All in Technology
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
1
550
Azure Well-Architected Framework入門
tomokusaba
1
350
Why Governance Matters: The Key to Reducing Risk Without Slowing Down
sarahjwells
0
120
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
240
[Keynote] What do you need to know about DevEx in 2025
salaboy
0
130
いまさら聞けない ABテスト入門
skmr2348
1
220
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
3
770
オープンソースでどこまでできる?フォーマル検証チャレンジ
msyksphinz
0
120
o11yで育てる、強い内製開発組織
_awache
3
140
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
650
社内報はAIにやらせよう / Let AI handle the company newsletter
saka2jp
8
1.3k
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3k
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
Building Applications with DynamoDB
mza
96
6.7k
Making Projects Easy
brettharned
119
6.4k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Code Reviewing Like a Champion
maltzj
525
40k
Unsuck your backbone
ammeep
671
58k
Optimizing for Happiness
mojombo
379
70k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
51k
Why Our Code Smells
bkeepers
PRO
339
57k
Code Review Best Practice
trishagee
72
19k
Gamification - CAS2011
davidbonilla
81
5.5k
4 Signs Your Business is Dying
shpigford
185
22k
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