Slide 1

Slide 1 text

GKE + Vuls コンテナを用いた 脆弱性診断サーバ

Slide 2

Slide 2 text

はじめに ▸ 普段は熱烈なA○○信者です ▸ 数週間前までKubernetes is 何状態でした ▸ 今回はGKEをちゃんと利用しました ▸ 生温かい目で見守っていただけると幸いです 2

Slide 3

Slide 3 text

ねずみさん家。 Yuki.Teraoka@yktr_sre 株式会社ビヨンド システムソリューション部 SREチーム SRE4年目 サーバのことを全部丸投げされる人 3

Slide 4

Slide 4 text

アジェンダ ▸ そもそも脆弱性って? ▸ 脆弱性との戦い ▸ 脆弱性対応の効率化 ▸ GKE for Vuls ▸ 使用ツールと仕組みの解説 4

Slide 5

Slide 5 text

脆弱性って? ▸ コンピュータソフトウェアの欠陥 ▸ セキュリティホールと呼ばれる ▹ 本来操作できないはずの操作が出来る ▹ 見えるべきではない情報が見える ▸ 攻撃されるとたちまち悪影響が ▹ 秘匿情報の外部への漏洩 ▹ システムの乗っ取り、破壊 5

Slide 6

Slide 6 text

脆弱性との戦い ▸ 脆弱性に対しては対策を打たなければならない ▹ 脆弱性情報の取得 ▹ 緊急性/影響範囲の把握 ▹ 修正パッチリリース情報の取得 ▹ パッチの適用 6

Slide 7

Slide 7 text

脆弱性との戦い ▸ 都度対策したとしても。。。 ▹ 脆弱性自体は0にならない ▹ 対策した直後にまた新たな脆弱性 ▹ 正直いたちごっこ ▹ それでも放置できないというジレンマ ▹ どげんかせんといかん 7

Slide 8

Slide 8 text

脆弱性対応の効率化 ▸ 問題点を洗い出してみると ▹ 監視対象のサーバが増えると追いきれない ▹ 種類ごとの緊急度が把握できない ▹ 影響を受ける環境を把握するのが難しい 8

Slide 9

Slide 9 text

脆弱性対応の効率化 ▸ 理想としては ▹ サーバが増えても情報を把握できる ▹ 緊急度に応じて対応の要否や対応までの時間を 決定できる ▹ サーバごとに該当する脆弱性がどれかわかる ▹ 定期的に自動で脆弱性診断が行える ▸ 手作業では厳しいので仕組みを考える必要がある 9

Slide 10

Slide 10 text

GKE for Vuls ▸ 仕組みを考えました( ▹ インフラにGoogle Kubernetes Engineを採用 ▹ Vulsを使って定期的リモートスキャン ▹ スキャンした結果をチャットに通知 10

Slide 11

Slide 11 text

使用ツールと仕組みの解説 ▸ Vulsとは ▹ Linux/FreeBSD向けの脆弱性スキャンツール ▹ OSSであり、Golangで開発されている ▹ エージェントレスで導入が簡単 ▹ スキャン結果をSlackなどに通知できる 11

Slide 12

Slide 12 text

使用ツールと仕組みの解説 ▸ 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

Slide 13

Slide 13 text

使用ツールと仕組みの解説 ▸ 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

Slide 14

Slide 14 text

使用ツールと仕組みの解説 ▸ 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

Slide 15

Slide 15 text

使用ツールと仕組みの解説 ▸ 特徴 ▹ PodのIPを固定するためCloud NATを利用 ▹ そのため限定公開クラスタになっている ▹ Nodeはプリエンプティブインスタンスで起動 ▹ リソースは全てTerraformでコード化 15

Slide 16

Slide 16 text

使用ツールと仕組みの解説 16

Slide 17

Slide 17 text

使用ツールと仕組みの解説 17

Slide 18

Slide 18 text

使用ツールと仕組みの解説 18

Slide 19

Slide 19 text

使用ツールと仕組みの解説 19

Slide 20

Slide 20 text

使用ツールと仕組みの解説 20

Slide 21

Slide 21 text

使用ツールと仕組みの解説 21

Slide 22

Slide 22 text

使用ツールと仕組みの解説 22

Slide 23

Slide 23 text

使用ツールと仕組みの解説 ▸ Kubernetesのリソースは以下の通り ▹ PersistentVolumeClaim ▹ ConfigMap ▹ Secret ▹ kubectl create secret generic vuls-scan-key --from-file=id_rsa=[path/to/secret/key/file] ▹ Job ▹ CronJob 23

Slide 24

Slide 24 text

使用ツールと仕組みの解説 ▸ 特徴 ▹ Vulsがスキャン時に利用するデータベース用に PersistentVolumeClaimで永続ボリュームを作成 ▹ ConfigMapで必要な設定ファイルを管理 ▹ vulsの設定ファイル(config.toml) ▹ SSHのconfigファイル 24

Slide 25

Slide 25 text

使用ツールと仕組みの解説 ▸ 特徴 ▹ SSH接続に必要な秘密鍵はyamlでは管理しない ▹ Secretリソースを利用している ▹ Jobでスキャンで使う脆弱性データベースを取得 ▹ CronJobで定期スキャンと結果の送信を行う 25

Slide 26

Slide 26 text

使用ツールと仕組みの解説 26

Slide 27

Slide 27 text

使用ツールと仕組みの解説 27

Slide 28

Slide 28 text

使用ツールと仕組みの解説 28

Slide 29

Slide 29 text

使用ツールと仕組みの解説 29

Slide 30

Slide 30 text

使用ツールと仕組みの解説 30

Slide 31

Slide 31 text

使用ツールと仕組みの解説 31

Slide 32

Slide 32 text

使用ツールと仕組みの解説 32

Slide 33

Slide 33 text

使用ツールと仕組みの解説 33

Slide 34

Slide 34 text

使用ツールと仕組みの解説 34

Slide 35

Slide 35 text

使用ツールと仕組みの解説 35

Slide 36

Slide 36 text

使用ツールと仕組みの解説 36

Slide 37

Slide 37 text

使用ツールと仕組みの解説 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に アップロードするので良ければ見てみてください!

Slide 38

Slide 38 text

使用ツールと仕組みの解説 38

Slide 39

Slide 39 text

まとめ 39 ▸ 脆弱性は0にならないけど見逃せない ▸ 少しでも効率化したいのでこの仕組みを作った ▸ Kubernetesを使っていると案の定yaml地獄に ▹ helmを使うとなお管理しやすくなるかも ▸ 気になった方は是非試してみてください! ▸ 皆様の脆弱性対応のお供になると幸いです

Slide 40

Slide 40 text

Thank you for listening! 40