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