View
2
Download
0
Category
Preview:
Citation preview
Confidential & Proprietary
グーグル・クラウド・ジャパン合同会社 カスタマーエンジニア
田中 宏樹
コンテナ開発プラットフォームにGKE を選択すべき 7 つ 理由
グーグル・クラウド・ジャパン合同会社 カスタマーエンジニア
岩成 祐樹
Confidential & Proprietary
グーグル・クラウド・ジャパン合同会社 カスタマーエンジニア
田中 宏樹
コンテナ開発プラットフォームにGKE を選択すべき 7 つ 5 つ 理由
グーグル・クラウド・ジャパン合同会社 カスタマーエンジニア
岩成 祐樹
5 つ 理由
1. Security
2. Network
3. Hybrid Cloud
4. Observability
5. Contribution
1. Security
Google Cloud セキュリティ機能が評価され、Forrester Research “Public Cloud PlatformNative Security, Q2 2018” レポートでリーダーに選出される
The Forrester Wave™: Public Cloud Platform Native Security Q2 2018. The Forrester Wave™ is copyrighted by Forrester Research, Inc. Forrester and Forrester Wave™ are trademarks of Forrester Research, Inc. The Forrester Wave™ is a graphical representation of Forrester's call on a market and is plotted using a detailed spreadsheet with exposed scores, weightings, and comments. Forrester does not endorse any vendor, product, or service depicted in the Forrester Wave. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.
セキュリティがクラウド 長所にエンタープライズでクラウド利用が増加している理由
1. アジリティ 重要性（45 %）
2. セキュリティへ 信頼（44 %）
3. 経費節減（34 %）
MIT Sloan Management Review 調査レポートによる
（回答者 509 人以上 経営者と IT リーダー）
徹底的な防御がデフォルトで ON
運用とデバイス セ
キュリティ
ハードウェア インフラ サービス展開
アイデンティティ
ストレージ
サービス
インターネット通信
● k8s セキュリティ機能を使って、ID、シークレット、ネットワークをど ように守るか？
● GKEに備わる IAM、audit logging、networkingなど 機能をど ように活用するか？
● コンテナイメージに脆弱性が無いことをど ように保証するか？
● ビルドされたイメージが、デプロイまでに改竄されないことをどように保証するか？
● コンテナが不審な挙動をしたときにど ように検知するか？
● そ 際、ワークロードをど ように守り、分離するか？
● ど ようにコンテナ デプロイを安全にスケールさせるか？
コンテナ セキュリティ？
INFRASTRUCTURE SECURITY
インフラ コンテナを開発する に安全か
SOFTWARE SUPPLY CHAIN
作成したコンテナビルド、デプロイして問題ないか？
RUNTIME SECURITY
作成したコンテナ実行して問題ないか？
● 権限昇格
● 機密情報 漏洩
● Kubernetes API 漏洩
● 必要以上 権限を持つユーザ
コンテナセキュリティ 脅威とリスク
● パッチ適用漏れによる脆弱性
● サプライチェーンに起因する脆弱性
● 共通ライブラリ ゼロデイ脆弱性
● DDoS
● Node へ 不正アクセス
● Container escape
● Flood event pipeline
INFRASTRUCTURE SECURITY
SOFTWARE SUPPLY CHAIN
RUNTIME SECURITY
● k8s セキュリティ機能を使って、ID、シークレット、ネットワークをど ように守るか？
● GKEに備わる IAM、audit logging、networkingなど 機能をど ように活用するか？
● コンテナイメージに脆弱性が無いことをど ように保証するか？
● ビルドされたイメージが、デプロイまでに改竄されないことをどように保証するか？
● コンテナが不審な挙動をしたときにど ように検知するか？
● そ 際、ワークロードをど ように守り、分離するか？
● ど ようにコンテナ デプロイを安全にスケールさせるか？
コンテナ セキュリティ？
INFRASTRUCTURE SECURITY
インフラ コンテナを開発する に安全か
SOFTWARE SUPPLY CHAIN
作成したコンテナビルド、デプロイして問題ないか？
RUNTIME SECURITY
作成したコンテナ実行して問題ないか？
GKE: Use RBAC and IAM
Infra secInfrastructure security
GCP Project
Cluster
Node
NamespacePod Container
Container
プロジェクトレベルで IAM を利用ロールを設定する● Cluster Admin: クラスタを管理● Container Developer: クラスタへ
APIアクセス
クラスタ/ネームスペースレベルでRBAC を利用個別 クラスタやネームスペースへ 権限を設定
プライベートクラスタ承認済みネットワーク
Trusted
Virtual Private Cloud (VPC)
Kubernetes Engine Cluster
Node Node Node
Google Kubernetes Engine
Kubernetes Master
Trusted
On-prem
Host HostVPN
Untrusted
Internet
Infrastructure security
Cloud Armor
ユースケース
● インフラに対する DDoS 攻撃対策
● IP ブラックリスト/ホワイトリスト
● 地域 (Geo) ベース アクセス制限 Alpha
● SQLi / XSS 防御 Alpha
● カスタムルール 作成 Alpha
● Stackdriver による証跡
スケーラブルな DDoS 対策 / WAF
https://cloud.google.com/armor/
Infrastructure security
BackendConfig BETA
● Cloud Content Delivery Network (Cloud CDN)● Cloud Armor● Cloud Identity-Aware Proxy (Cloud IAP)
利用可能な HTTP(S) Load Balancing 機能
BackendConfig と ？
● Kubernetes Engine Ingress controller で利用されるカスタムリソース定義
● BackendConfig オブジェクトとサービスポートを紐付けることで GCLB 用 設定が可能
● GKE version 1.10.5-gke.3 以降で利用可能
Infrastructure security
● k8s セキュリティ機能を使って、ID、シークレット、ネットワークをど ように守るか？
● GKEに備わる IAM、audit logging、networkingなど 機能をど ように活用するか？
● コンテナイメージに脆弱性が無いことをど ように保証するか？
● ビルドされたイメージが、デプロイまでに改竄されないことをどように保証するか？
● コンテナが不審な挙動をしたときにど ように検知するか？
● そ 際、ワークロードをど ように守り、分離するか？
● ど ようにコンテナ デプロイを安全にスケールさせるか？
コンテナ セキュリティ？
INFRASTRUCTURE SECURITY
インフラ コンテナを開発する に安全か
SOFTWARE SUPPLY CHAIN
作成したコンテナビルド、デプロイして問題ないか？
RUNTIME SECURITY
作成したコンテナ実行して問題ないか？
CI/CD パイプライン
信頼できないデプロイを 止めてくれない
Software Supply Chain
Software supply chain
“QAされたコードだけを実行したい”
“新たな脆弱性に影響されるジョブを動かしてないだろうか？ ”
“ボブ ビルドを開始できる、しかしアリス 本番環境向けに保証したい”
Build & Deploy
CI/CD pipeline
Build
Test
Scan
Anal
ysis
QA
Binary authorizationAdmission controller
イメージ メタデータAttestations, findings, etc.
本番環境
Enforce policies for: signatures, images,
severity of vulnerabilities,
image location, etc.
安全なベースイメージ
Develop
Software Supply Chain
Container Registry 脆弱性スキャン
コンテナレジストリ 脆弱性スキャン 、CI / CD パイプライン 早い段階でセキュリティ上 脆弱性を特定します
Ubuntu、Debian、Alpine パッケージにある
脆弱性を特定します。
常時更新されるデータベースにより、スキャンが常に
最新であることを保証します。
検出可能な脆弱性を拡張するために、既存 ツールを
プラグインすることができます。
Software supply chain
Binary Authorization
Binary Authorization 、 信頼されたコンテナイメージ みを GKE 上にデプロイすることを保証する セキュリティコントロール機能です
検証済みイメージ みが、ビルドリリースプロセス
と統合できます
Kubernetes Engine にデプロイする前にシグネチャ
検証を強制することができます。
開発中に、信頼された認証局により署名されたイメージが
必要となります。
Software supply chain
● k8s セキュリティ機能を使って、ID、シークレット、ネットワークをど ように守るか？
● GKEに備わる IAM、audit logging、networkingなど 機能をど ように活用するか？
● コンテナイメージに脆弱性が無いことをど ように保証するか？
● ビルドされたイメージが、デプロイまでに改竄されないことをどように保証するか？
● コンテナが不審な挙動をしたときにど ように検知するか？
● そ 際、ワークロードをど ように守り、分離するか？
● ど ようにコンテナ デプロイを安全にスケールさせるか？
コンテナ セキュリティ？
INFRASTRUCTURE SECURITY
インフラ コンテナを開発する に安全か
SOFTWARE SUPPLY CHAIN
作成したコンテナビルド、デプロイして問題ないか？
RUNTIME SECURITY
作成したコンテナ実行して問題ないか？
Container Optimized OS● Google Compute Engine, Kubernetes Engine で利用可能なセキュア・軽量 OS
○ Chromium OS ベース
○ 最低限 プロセス み動作
○ ブート時、ブートイメージ 改竄チェック
○ 大部分が read only もしく ephemeral fs○ コンテナ sandbox で動作
○ AppArmor によるプロセス制限
○ サービス listen ポート 最小化
○ 自動 OS アップデート
https://cloud.google.com/container-optimized-os/docs/concepts/security
Runtime security
コンテナランタイム “runc” 脆弱性 (CVE-2019-5736)
2019 年 2 月 11 日にコンテナランタイム “runc” に、ホスト上 root 権限を取得できてしまう脆弱性が見つかったが、Container Optimized OS でこ 脆弱性による悪用 不可能だったため、特別なアクションを必要としなかった。
“Ubuntu ノード みが影響を受けます。COS ノード 影響を受けません。 ”
https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runc
Runtime security
Runtime security partners in Cloud SCC BETA
Cloud Security Command Center
5 partner integrations
Runtime security
2. Network
cluster
様々な GCP サービスと 統合
Google Kubernetes Engine
Google ManagedKubernetes Master
node-pool
Node NodeNode
Automated Operations
Node
StackdriverMonitoring
StackdriverLogging
Logging & Monitoring
+Stackdriver Kubernetes
Monitoring BETA
ContainerRegistry
Container Image
Cloud LoadBalancing
Network Services
CloudBuild
CI / CD
リポジトリから コンテナ起動
Inboundトラフィック グローバル負荷分散
ビルドしたイメージPush
統合されたロギング及びモニタリング
デベロッパー向けサービス
ネットワークサービス
モニタリングサービス
Google Cloud Load Balancing
GoogleEdge POP
GoogleEdge POP
GoogleEdge POP
Cloud LoadBalancing
X.X.X.XUnique Anycast Address
US EMEA APAC
VPC
us-central1 europe-west1 asia-northeast1
KubernetesEngine
KubernetesEngine
KubernetesEngine
世界で一つ エニーキャストアドレスに対するリクエストを、複数 リージョンにまたがってデプロイされた GKE クラスタに対してルーティングすることが可能
Google グローバルインフラで提供される Cloud CDN と LB
FASTER (US, JP, TW) 2016
Unity (US, JP) 2010SJC (JP, HK, SG) 2013
エッジ POP（>100）
リースまた 自社所有 光ファイバー
#
#
開設予定 リージョンとゾーン数
現在 リージョンとゾーン数
3
3
2
3
3
3
3
24
3
3
2
Frankfurt
Singapore
S CarolinaN Virginia
BelgiumLondon
TaiwanMumbai
Sydney
Oregon Iowa
São Paulo
Finland
Tokyo
Montreal
California
Netherlands
3
3
3
https://peering.google.comhttps://cloud.google.com/compute/docs/regions-zones/regions-zones
4
Google Edge POP
Google Region
Google Backbone
3
3
9 つ リージョン、27 ゾーン、100 以上 接続ポイント（POP）、および延べ数十万 km に及ぶ光ファイバー ケーブルで構築され、適切にプロビジョニングされたグローバル ネットワーク
Container Native Load Balancing BETA
https://cloud.google.com/blog/products/containers-kubernetes/introducing-container-native-load-balancing-on-google-kubernetes-engine
Container Native Load Balancing BETA
HTTP(S) ロードバランサーから
直接 Pod IP を参照
“double-hop” 問題を解決
Latency とルーティング性能を改善
VPC-native clusters かつ kubernetes version 1.10+ で利用可能
Master
CC
Nodes
C
Nodes
3. Hybrid Cloud
ゴール : コードをどこでも実行できる環境を整える
オンプレやクラウドにとらわれずに様々な環境でワーク
ロードが実行できる環境
求められるリソースに最適な環境を選ぶ
Hybrid Cloud による適材適所
GCP Solution : GKE On-Prem BETA
オンプレミス クラスタを Google Cloud Console から一元的に管理
Cloud Identity かオンプレミス IdP を使って
クラスタへ アクセスを制御
クラウド側と同様に Stackdriver による
可観測性を提供
オンプレミスとクラウド 間でワークロードを
自由に移動可能
クラスタ集中管理 メリット
GKE と GKE On-Premで同じツールを使って
クラスタ 構築、構成、管理を実施
同一 クラスタ環境 (k8s version, OS image, plug-ins, components configuration)
API gateway
Services A Services BGoogle Kubernetes Engine
Google Cloud Load Balancer
On-prem
Monolith
Mercari様事例 On-premから 移行
TLS終端
DDoS対策
ルーティング
ロードバランシング
AuthZ/AuthN
リソース 利用
セルフヒーリング
オートスケーリング
サービスディスカバリー
Cloud マネージドサービ
スが使えるサービス
Hybrid Cloud事例紹介
API gateway
Services A Services BGoogle Kubernetes Engine
Google Cloud Load Balancer
Monolith
GKE on-prem
Services C
Istio Service Mesh
On-prem
proxy
proxyサービス間
コミュニケーション
Mercari様事例 今後 展望
Hybrid Cloud事例紹介
4. Observability
Logging and Monitoring is key to Observability
Logging
複数 アプリケーションや
サービスから発生するログ
収集
GCP内部 情報に加えて
GCP 外部で発生するログ
についても収集できる基盤
が必要
Monitoring
収集したログや指標を見え
る化し、アクションを提供す
る一連 プロセス
アプリケーション エラーが
発生したり、閾値を超えた
際に、アラートを適切な担当
者に正しく送る機能が必要
Comprehensive Observability at Scale
Developer
最良 システムを構築するために 、インフラストラクチャ、ワークロード、サービスを継続モニタリングが必要
SecOps
セキュリティポリシーを見直してコンプライアンスを強化ためぶが、すべて クラスタ監査ログ 収集が必要
DevOps/SRE
パフォーマンス 問題を調査するために 、すべてクラスター 状況 理解が必要
統合管理プラットフォーム
GCP Solution : Stackdriverアプリケーション開発者と運用担当者にLogging と Monitoring 機能を提供するため 統合基盤
Stackdrvier ミッション 、アプリケーション 開発
速度と、運用 可用性を保てるように助けること
Kubernets ワーク
ロードに最適化された Stackdriver ツール
Monitoring に加えて Logging も 1 つ 管理
画面で提供
Stackdriver Kubernetes Monitoring BETA
Works With Open Source
● Google にインスパイアされたエンジニアが
Prometheus イニシアチブをリード
● Open Source Promethus と、Stackdriver K8S Monitoring シームレスなインテグレーショ
ンPrometheus
5. Conribution
コンテナと Kubernetes 歴史
Kubernetes 1.0 - July 15
First Github commit for Kube - Jun 14
Public Beta of Solaris Containers
Birth of Borg, 3-4 Google Engineers working to
automate cluster management.
2003 201820092006 20152012
Work begins to opensource Google’s Borg as Kubernetes
Process Containers launched by Google now known as cgroups and
merged with Linux Kernel. LXC launched, complete
Linux container manager
Docker Launched 2013
GKE on Prem
Announced
Gvisor
KnativeIstio 1.0
Istio 0.1
Envoy 1.0
GKE G
A- Aug 15
GKE Alpha - Nov 14
D'où Venons GKE?Que Sommes GKE?
Où Allons GKE?
GKE is going to ...
To be ReliableTo be Scalable
To be Open
To be Reliable
Regional clusters GA since Q3’18● Kubernetes コントロールプ
レーンを３つ ゾーン（同一リージョン）で実行する
● 99.95% SLO for Kubernetes API
○ ゾーンクラスタ 場合 99.5%
● 3 つ ゾーンに 3 つ クラスタ マスターを作成
● デフォルトで 3 つ ゾーンにノードを作成。必要に応じて、指定した数 ゾーンにノード 作成が可能。
Zone BZone A Zone C
Regional Control Plane
Nodes Nodes Nodes
Regional Persistent Disks BETA
● セカンダリ ゾーン Disk に対
してデータをミラーリング
● ゾーン障害があった場合、 GKE コンテナを問題 ないゾーン
にマイグレーション、強制的にミ
ラーリングしてある Disk をア
タッチ
● DB 等 ステートフルなアプリ
ケーションに最適な高可用性ソ
リューションが構築可能
Zone BZone A Zone C
Regional Control Plane
Nodes Nodes Nodes
To be Scalable
Scalability of GKEPod ・ Node 双方に対して水平／垂直 スケーリ
ング機能を提供
GKE スケーリング機能
● HPA : Pod 水平スケーリング
● VPA : Pod 垂直スケーリング BETA● CA : Node 水平スケーリング
＋
● Node Auto-Provisioning BETA
Node Auto-Provisioning Beta
● Node Auto-Provisioning（NAP）4 番目 オートスケール 方法を提供。
● 適切なサイズ インスタンスを持つまったく新しいノードプールを作成
Master
Node pool A Node pool B
1. Deploy new large workload
2. Scheduler determines existing node pool’s instance types are too small for the new workload
3. Provisions new node pool with bigger instances
4. Over time, HPA, CA, and NAP will work together to optimize the cluster
To be Open
OSS friendly ecosystemGoogle Container Toolsgithub.com/GoogleContainerTools
Skaffoldgithub.com/GoogleContainerTools/skaffold
Kanikogithub.com/GoogleContainerTools/kaniko
Knativegithub.com/knative/
Thank you
Recommended