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
420
20190525_GCPUG_KYOTO_登壇資料.pdf
nezumisannn
May 25, 2019
Tweet
Share
More Decks by nezumisannn
See All by nezumisannn
20230511_AWSにおけるコンテナサービスの選択とIaC実装例.pdf
nezumisannn
0
880
リーダーになって1年経過して_取り組んできたことと大事にしている考え方_の裏側_.pdf
nezumisannn
0
49
20211118_GKEにおける高負荷時のPodとWorker_Nodeの挙動について.pdf
nezumisannn
0
93
20211014_Alibaba_Cloud_Container_Service_for_KubernetesにおけるServerless_Kubernetesの概要とManaged_Kubernetesとの違い.pdf
nezumisannn
0
52
20211008_ApsaraDB_for_PolarDBとAWS_Auroraの機能比較.pdf
nezumisannn
1
82
20210122_AlibabaCloudパートナーサミット_Terraform_Cloudを活用するマルチクラウドオートメーション.pdf
nezumisannn
0
35
20201203_AlibabaCloudセミナー_ApsaraDB_for_PolarDB_の便利機能と競合DBとの差別化ポイントの紹介.pdf
nezumisannn
0
12
20200617_ビヨンド勉強会_24_Terraformにおけるディレクトリ構造のプラクティスと記述事例.pdf
nezumisannn
0
250
20200522_FGDC_Terraform_CloudでGitOpsを使用したCI_CDパイプラインを構築する.pdf
nezumisannn
0
370
Other Decks in Technology
See All in Technology
[2024年3月版] Databricksのシステムアーキテクチャ
databricksjapan
8
1.9k
"好き"との生活/Regularly update profile with GitHub Actions
judeeeee
0
150
Four keys改善の取り組み事例紹介
sansantech
PRO
3
230
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
1
190
社内勉強会運営のコツ
senoo
6
1.1k
Databricks における 『MLOps』
databricksjapan
2
140
Tebiki株式会社 エンジニア採用資料
tebiki
0
4.1k
[PlatformCon 24] Platform Orchestrators: The Missing Middle of Internal Developer Platforms?
danielbryantuk
1
180
コンテナセキュリティの基本と脅威への対策
kyohmizu
3
690
レガシーをぶっ壊せ。AEONで始めるDevRelの話 / Qiita Night 2024-2-22
aeonpeople
3
150
コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える / Scalable and Secure Infrastructure as Code Pipeline for a Compound Startup
yuyatakeyama
3
2.2k
2024/4/26 コンピュータ歴史博物館解説告知
toshi_atsumi
0
200
Featured
See All Featured
Faster Mobile Websites
deanohume
297
30k
Atom: Resistance is Futile
akmur
258
25k
How STYLIGHT went responsive
nonsquared
92
4.8k
Raft: Consensus for Rubyists
vanstee
132
6.2k
Facilitating Awesome Meetings
lara
41
5.6k
Fantastic passwords and where to find them - at NoRuKo
philnash
36
2.5k
The Invisible Customer
myddelton
114
12k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
GraphQLとの向き合い方2022年版
quramy
31
12k
In The Pink: A Labor of Love
frogandcode
138
21k
The Cost Of JavaScript in 2023
addyosmani
14
3.8k
Designing Experiences People Love
moore
136
23k
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