20190716 クラスメソッド×クリエーションライン共催イベント「Kubernetesの導入時こそ、ITセキュリティを見直す好機！」の発表資料です。

1. クリエーションライン株式会社
会社概要

2. Copyright© Creationline,inc. All rights reserved.
2
社名：クリエーションライン株式会社
代表：安田 忠弘
設立：2006年1月
資本金：215,572,000円（資本準備金を含む）
従業員数：130名（業務委託/契約社員含む）

3. Copyright© Creationline,inc. All rights reserved.
3
製品取扱の推移
Chef
GitLa
b
Docker
Elasti
c
MongoDB
Hashicorp
Neo4j
取扱OSS製品の推移
Products Handling History 2018
2012
2014
2015
2016
2006
創業
2009
201
1
Aqua
Security2017

4. Copyright© Creationline,inc. All rights reserved.
日本国内で唯一Kubernetes Certified Service Providerと
Kubernetes Training Partner を所有する事業会社です。
4
Kubernetes Certifcation

5. Copyright© Creationline,inc. All rights reserved.
• 2018年より、Kubernetesのセキュリティソリュ
ーションとしてAqua Security社と販社契約を締
結、日本国内で販売開始
5

6. Kubernetesの導入時こそ、
ITセキュリティを見直す好機！
クリエーションライン （株）
CSO （Chief Strategy Officer)：鈴木いっぺい

7. Operating Kubernetes
Clusters and Applications
Safely
• Kubernetes上でアプリ運用を
セキュアに行うための考え方
を簡潔に説明
• Aqua Security社の推進する
DevSecOpsのコンセプトの源
にもなっている。

8. 1. Kubernetesセキュリティへの取り組み

9. K8S固有の攻撃方法は複数存在
マシン／VM
へ直接アクセス
K8S APIもしくは
プロキシ経由
Kublet API 経由
コンテナの脆弱性、
もしくはボリューム
マウントから
データ流出
etcd API へ
アクセス
Control Planeへの
データの流れを
インターセプト
アプリへの
トラフィックを
インターセプト
アプリへに脆弱性
を埋め込む

10. K8Sセキュリティの基本
階層的に守る
K8sクラスタ攻撃は、複数の層で防御の戦略を立てる
権限提供は必要最低限に
リソースやその属性情報へのアクセスは、必要最低限の機能の権限
提供に留める
攻撃対象面積を最小に
アプリケーションのコード量を減らす

11. 4つのキーポイント
1. セキュアなKubernetes環境の設
定
2. アプリへの攻撃から守る
3. 秘密情報の管理
4. 他、固有な条件／攻撃への対応

12. 1. セキュアなKubernetesの設
定
クラスタの保護
認証
承認

13. セキュアなKubernetesの設定
クラスタの保護
認証
承認
API サーバ
Kubelet
etcd の安全な運用
Kubernetes ダッシュボード
設定情報の検証

14. APIサーバ設定
--insecure-port flag を 0 に
--insecure-bind-address が設定されて
いない事を確認
セキュアでないポートを閉じる
TLSコネクションを通したAPIはセキュ
アなポートからのみアクセス可能
API サーバ
Kubelet
etcd の安全な運用
Kubernetes ダッシュボード
設定情報の検証
クラスタの保護

15. 認証されたリクエストのみにAPIアク
セスを許容（匿名のリクエストは拒否
）—anonymous-auth=false
アクセス制御を強化（認証されないア
クションは阻止）
Kubelet 証明書のロテーション
（—rotate-certificates の設定で証明書
の自動的なロテーションを提供）
API サーバ
Kubelet
etcd の安全な運用
Kubernetes ダッシュボード
設定情報の検証
クラスタの保護

16. etcdへのアクセスは、認証された
場合のみに限定
さらに、etcd上で管理されるデー
タは暗号化
API サーバ
Kubelet
etcd の安全な運用
Kubernetes ダッシュボード
設定情報の検証
クラスタの保護

17. パスワードで認証されたアクセスの
みを許可（Tesla事件）
RBACをアクセス管理に徹底
ダッシュボード上のサービスアカウ
ントは限定的な権限を提供
ダッシュボードをインターネット上
で公開しない
API サーバ
Kubelet
etcd の安全な運用
Kubernetes ダッシュボード
設定情報の検証
クラスタの保護

18. CIS セキュリティベンチマーク
デプロイメントの設定のベストプラク
ティス情報を参照する
侵入テスト
侵入テストの専門家を採用
kube-hunterを活用
API サーバ
Kubelet
etcd の安全な運用
Kubernetes ダッシュボード
設定情報の検証
クラスタの保護

19. クラスタの保護
認証
承認
ID管理
認証コンセプト
認証戦略
ツールやベストプラクティス

20. ユーザ管理は下記の前提
Kubernetes外のディレクトリサービス
（LDAP等）
ログインサービス（SAMLやKerberos
）
アプリに対してもID管理が可能で、サー
ビスアカウントとして上位のリソースで
管理
ID管理
認証コンセプト
認証戦略
ツールやベストプラクティス
認証

21. 認証プラグイン（Authentication Plug-In
）を経由して、クライアントから提示さ
れたIDの認証を指定した認証サーバから
受ける
ID管理
認証コンセプト
認証戦略
ツールやベストプラクティス
認証

22. 静的なパスワード、もしくはトークンファイ
ル
X.509 証明書
OpenID Connect (OIDC)
Bootstrap トークン
LDAP、SAML、Kerberos
認証プロキシ
Webhook トークン認証
ID管理
認証コンセプト
認証戦略
ツールやベストプラクティス

23. Keycloak
既存LDAPサーバとの接続を提供するIAMソリューション
Dex
アプリの認証にOIDCをサポート
AWS IAM Authenticator for Kubernetes
アマゾンとHeptio社が開発
Guard
LDAPに加え、GitHub、GoogleのID管理プロバイダーを
Kubernetesへのログインをサポート
ID管理
認証コンセプト
認証戦略
ツールやベストプラクティス
認証

24. クラスタの保護
認証
承認
承認のコンセプト
承認のモード
RBACを利用したアクセス管理
ツールやベストプラクティス

25. 承認のコンセプト
承認のモード
RBACを利用したアクセス管理
ツールやベストプラクティス

26. Node 承認
搭載されるポッド上にKubletの稼働承認を行う
属性ベースのアクセス管理 (ABAC)
ユーザ属性、リソース属性、オブジェクト、等
ウェブフック
HTTPコールバック機能：K8s外部承認
ロールベースのアクセス管理 (RBAC)
ベストプラクティス
Kubernetesが提供するデフォルトのロール
承認のコンセプト
承認のモード
RBACを利用したアクセス管理
ツールやベストプラクティス

27. Kubernetesが提供するデフォルト
のロール
承認のコンセプト
承認のモード
RBACを利用したアクセス管理
ツールやベストプラクティス
ベストプラクティス

28. ネームスペース内でリソース（サービス、ポッド）のアクセス承認
ロールとロールバインディングを使用
複数のネームスペースに同じロールを適用したい場合
クラスターのロールを定義し、ロールバイディング機能を使ってロール
をユーザとかサービスアカウント等を対象にバインドする。
クラスタ全体に渡ったリソース
ノードや、ネームスペース全般のリソースに対してアクセスを提供した
い場合は、クラスターロールバインディングをもつクラスタロールを使
用する
ベストプラクティス

29. エンドユーザ向けのロール
例：cluster-admin, admin, edit, view
Control Planeコンポーネント
例：system:kube-controller-manager, system:node
その他のコンポーネント
例：system:persistent-volume-provisioner（動的ボリュームプロ
ビジョニング）
Kubernetesが提供するデフォルトのロー
ル

30. ツールやベストプラクティ
ス
audit2rbac
特定のアプリに必要な許可を自動的に決定しRBACロールやバインディングを設定
rbac-manager
ロールバインディングやサービスアカウントの管理を容易にするKubernetesオペレータ
kube2iam
Annotationに基づいてAWS IAM設定情報をコンテナに提供する
ベストプラクティス
RBACを使用する
Kubernetsバージョンは、1.8以降にする
-- authorization-mode=RBAC パラメタをAPIサーバに引き渡す
デフォルトサービスアカウントのトークンを無効にする
専用のサービスアカウントを使用する

31. 2. アプリのワークロードを攻撃
から守る
コンテナイメージの保護
セキュアにコンテナを運用

32. コンテナイメージの保護
コンテナのイメージのスキャン
コンテナイメージのパッチ
CI/CDのベストプラクティス
イメージのストレージ
イメージのバーションの修正
信頼できるイメージのサプライチェーン
攻撃範囲を狭めるためにコード量を削減

33. コンテナのイメージのスキャ
ン
イメージに含まれるパッケージを最初にスキャンし
、既知の脆弱性の存在を報告する
定期的にイメージのスキャンを実施する事が重要

34. コンテナイメージのパッチ
デプロイされたコンテナに対する「パッチ」は、実
際には新規のコンテナイメージを作成し、再度コン
テナをデプロイする工程をさす。
自動ビルドはCIパイプライン、自動デプロイはCDパ
イプラインで定義される

35. CI/CDのベストプラクティ
ス
イメージスキャンはCI/CDパイプラインの中で自動化可
能

36. イメージのストレージ
セキュリティ意識の高い企業は、独自にプライベー
トレジストリを採用し、デプロイはこのレジストリ
に限定

37. イメージのバーションの修
正
コンテナイメージの最新（最も適切な）バージョン
を利用することを保証する

38. 信頼できるイメージのサプライチェー
ン
イメージレジストリから導入したバージョンが、改
ざんされていなく、純正であることを保証
Notary
Grafeas
in-toto project
他のベンダー開発ソリューション

39. 攻撃範囲を狭めるためにコード量を削減
イメージが小さいほど、攻撃可能な領域が小さくなる
SSHやその他のイメージはアプリケーションのコードに
は必要ない可能性が高い

40. セキュアにコンテナを運用
ルート権限は基本的に使わない
例外事項
ホストシステムに対してルート権限で変更
ノードに対して特定のポートをバインド
ランタイム時にコンテナ内にソフトウェアをインストール
Admission Control 機能
クラスタの管理者として設定可能なAdmission Controller機能が30以上APIサーバ内
に存在する。
セキュリティの境界線
ポリシー
セキュリティポリシー
ネットワークポリシー

41. 3. 秘密情報の管理
最低限の権利を提供する
コンテナ内のコードは必要以上のシークレットを
参照しない
秘密情報の暗号化
シークレットは記録時（at rest）と転送時（in
transit）の両方で暗号化（TLS）

42. 秘密情報の管理
Kubernetesのシークレット管理
Kubernetesのシークレットリソースタイプは、ポッドのYAML上にに文
字情報として記載せずにコードにシークレット情報を提供する仕組み
シークレットは通常はetcdにて管理
etcd内でのシークレット管理
base64（エンコーディング not encryption）
さらにディスク上でetcdクラスタを暗号することによってさらに気
密性を高くできる
3rdパーティのソリューション
HashiCorp Vault
CyberArk Conjur

43. 秘密情報の管理
シークレットをコンテナ内のコードに引き渡す
イメージ内においてシークレットをビルドしない
環境変数としてシークレットを引き渡す (12 factor app manifesto)
ファイルに対してシークレットを引き渡す
Kubernetesはボリュームマウントされたポッドに対してシーク
レットを引き渡す機能はサポート
シークレットの定期的変更と無効化
定期的にシークレットの値を変更することにより、攻撃を防止す
ることができる

44. 秘密情報の管理
コンテナ内からのシークレットへのアクセス
コンテナ内のツールが少ないほど、攻撃の可能性は低くなる
。（cat, more, less, 等）
シークレットを読めるコマンド自体をコンテナ内にビルドし
ないことも有効
Kubeletからのシークレットへのアクセス
node authorization機能が当該ノードにスケジュールされたノ
ードのみに関連したシークレットをKubletがアクセスできる
ように制限

45. 4. 他、固有な条件／攻撃への対応
監視、アラート、監査
ホストOSのセキュリティ
サンドボックス、ランタイム保護
マルチテナント運用
動的な許可の管理／運用
ネットワーク保護
YAMLの静的な分析
フォーク爆弾、リソースベースの攻撃
仮想通貨マイニング
Kubernetes自体のセキュリティアップデート

46. 監視、アラート、監査
Prometheus
KubernetesはAPIサーバ経由で、監査機能も提供し
、クラスターに関する動きを記録する機能を提供

47. ホストOSのセキュリティ
ホストOS
CoreOSのContianer Linux、RancherOS、RedHat社のAtomic等、ホスト
マシン上のコード量を最小限にするコンテナ運用に特化した手段は多い
Nodeの再利用
ノードはペットではなく家畜的な運用が必要
問題のあるノードは修正せず、入れ替える方式が最適。
その工程はInfrastructure as a Codeとして自動化、ノードの計画的な
再利用を容易に。

48. サンドボックス、ランタイム保
護
Sandboxing
同一ホスト上でも、個々のコンテナを分離することにより、任意のコ
ンテナ上のコードが他のコンテナに影響を与えないようにする
Runtime protection
コンテナ内で実行できるコードを限定する方法論
複数のプロジェクト
seccomp
AppArmor & SELinux
Kata Containers
gVisor
Nabla containers

49. マルチテナント運用
他のテナントに影響を及ぼす恐れのあるkubectlコマンドをコ
ントロールプレーンで他のユーザが使用できないようにする
ネームスペースベ-スのRBAC管理
コンテナ サンドボックス
ランタイムとネットワーク環境においては、コンテナのワー
クロードが他のリソースに影響を与えたり盗めないための配
慮
ネットワークポリシーを強化し、ネームスペース間でトラ
ッフィクが渡らないように制限

50. 動的な許可の管理／運用
リソースをクラスタへのデプロイする前に、柔軟で
拡張性のあるチェックを行うメカニズムを採用

51. ネットワーク保護
サービスメッシュ
双方向でTLSコネクション
ポッドを出入りするネットワークトラフィックを中継し、認証さ
れたコンポーネント間でTLSベースの通信を行なっている事を保
証
サービスメッシュネットワークポリシー
サービスメッシュはサービス間のコミュニケーションを管理し、
侵入者のクラスター間移動を制限できる

52. YAMLの静的な分析
kubetestたやkubesecのような分析ツールでYAML設
定ファイルの問題を発見する事が可能
ラベルに関すポリシーを設定する

53. フォーク爆弾、リソースベースの攻
撃
自分自身を複製し続ける機能を持つプロセスで、大
量のリソースを消費し、結果的にDDOSに近い攻撃
をうむ
ポッド内で稼働できるプロセスの上限を設定

54. 仮想通貨マイニング
Tesla社のシステムへの攻撃
https://redlock.io/blog/cryptojacking-tesla
クラスタ内は認証されているイメージしか稼働し
ないようにする
ランタイム時の保護
CPUの通常より高い利用率や想定されないリソー
スのスケールアウト等の異常な動きを検知する

55. Kubernetes自体のセキュリティアップデー
ト
Kubernetes自体が持つセキュリティの脆弱性は今後
発覚する事があり、CNCFのプロジェクトでは対応す
る活動を実施