※※2019 / 08 / 14 追記 YouTubeに投稿されたセッションのリンクを追加しました。※※
GKEによるコンテナセキュリティの道
- Ian Lewis
- Developer advocate
- YouTube
アプリ運用今昔
コンテナを導入する前
- 特定のサーバーにデプロイ
- 言語別のパッケージング
- ファイルコピーしてアプリを再起動
- ほとんどが手動
- セキュリティ
- ファイアウォールで守っていたとしても、超えられたら基本的には丸見え状態
コンテナの構成
- どのサーバーにどのコンテナをデプロイするかk8sに任せる感じ
- 仮に1コンテナを攻撃されても他のコンテナに移られにくい
コンテナ導入のメリット
- コンテナの中身関係なくリリース方法が一緒
- ステップが少ないので自動運用しやすい
コンテナ導入によるセキュリティの課題
- k8sへのアクセス権限の管理
- ファイアウォール
- セキュリティの新しい可能性
- 統一したモニタリング
- イメージスキャン
- イメージ署名
- サービスメッシュ
Googleのインフラセキュリティ
- 責任共有モデルに示されるように、各サービスに責任分界点がある
- サーバー自体は物理的に防いだり、一部の社員しかデータセンターに入れないようになっている
- ユーザーのアカウントは、原則Google社員でもさわれないようになっている(ユーザー側の許可が必要)
アプリのライフサイクルをセキュアに
- コンテナイメージの変更
- 脆弱性の有無
- 運用中のアプリが不正侵入されていないか
- 正しい権限のユーザー、不正アクセスの有無
CI/CD・ビルド
Google Container Registry
- Dockerコンテナイメージを保存・管理・保護する
- 安全なプライベートリポジトリである
デプロイ
Binary Authorization
- 信頼できるコンテナのみをGKEにデプロイ
- コンテナのリリース業務標準化
- 予防的なセキュリティ対策
- 脆弱性があるものについてはそもそもデプロイできないようにする
- Docker Hubのイメージも使えないようにすることができる
アプリ運用
GKE Sandbox
- GKEコンテナのセキュリティをさらに強化
- 徹底した防御をPodに追加
- 徹底した防御を簡単に導入
- 潜在的な攻撃を限定する
-
gVisor
- OSSツール
Anthos
- アプリの最新化(モダナイゼーション)
- ポリシーとセキュリティを大規模に自動化する
- 一貫性のある体験
- オンプレでもクラウドでも環境に整合性を持たせることができる
- サービスメッシュ
- アプリとアプリの間にプロキシを立てて、どこからのアクセスなのかをはっきりさせる
-
Istio
- サービス認証・ポリシー
- モニタリング
- トラフィックの制御
- プロキシとプロキシの間のネットワークは暗号化されて、アプリ間の通信が安全になる
Event Threat Detection
- GCP環境に存在するセキュリティの脅威を検出
- クラウドベースの脅威を迅速に検出
- 業界トップの脅威インテリジェンスを搭載
ユーザー・アクセス管理
Cloud IAM
- ユーザーが何をできるかを細かく指定できる
- 企業のID管理を簡素化
- 適切な役割
- きめ細かいリソース制御
Cloud Security Command Center
- GCP用の包括的なセキュリティ管理とデータリスクプラットフォーム
- クラウドデータやサービスの可視化と制御により脅威を防止
個人的ToDo
- Envoy
- gVisor
- Istio