KubernetesのRBACを掘り下げてみる（Kubernetes Novice Tokyo #17 発表資料）

© 2022 NTT DATA Corporation
KubernetesのRBACを掘り下げてみる
2022/03/23
Kubernetes Novice Tokyo #17

© 2022 NTT DATA Corporation 2
自己紹介
Name
Yusuke Nishikawa
Company
NTT DATA Corporation
Work
Financial Domain
Product Owner/Scrum Master
App Engineer

今回話すこと
• コンテナセキュリティにおけるRBACの位置づけ
• RBACに関わるリソースの概要と設計例
• 実PJでのメンテナンスの方法

コンテナセキュリティの全体像
• NIST SP800-190 アプリケーションコンテナセキュリティガイド
• クラウドネイティブセキュリティの４C

リスク分類詳細
イメージのリスク 1.1 Image vulnerabilities（脆弱性/NIST 3.1.1）
1.2 Image configuration defects（脆弱な設定/NIST 3.1.2）
1.3 Embedded malware（マルウェア/NIST 3.1.3）
1.4 Embedded clear text secrets（機密情報埋め込み/NIST 3.1.4）
1.5 Use of untrusted images（信頼できないイメージの実行/NIST 3.1.5）
レジストリのリスク 2.1 Insecure connections to registries（通信の盗聴/NIST 3.2.1）
2.2 Stale images in registries（古い脆弱なイメージの誤用/NIST 3.2.2）
2.3 Insufficient authentication and authorization restrictions（認証認可が不十分/NIST 3.2.3）
オーケストレータのリスク 3.1 Unbounded administrative access（オーケストレータへの過剰権限付与による侵害/NIST 3.3.1）
3.2 Unauthorized access（脆弱なID管理によるオーケストレータへの不正アクセス/NIST 3.3.2）
3.3 Poorly separated inter-container network traffic（コンテナ間ネットワークの不十分な距離/NIST 3.3.3）
3.4 Mixing of workload sensitivity levels（機密レベルの異なるコンテナが混在/NIST 3.3.4）
3.5 Orchestrator node trust（信頼できないノードの混入/NIST 3.3.5）
コンテナのリスク 4.1 Vulnerabilities within the runtime software（ランタイムソフトウェアの脆弱性/NIST 3.4.1）
4.2 Unbounded network access from containers（コンテナからの無制限のネットワークアクセス/NIST 3.4.2）
4.3 Insecure container runtime configurations（脆弱な設定/NIST 3.4.3）
4.4 App vulnerabilities（コンテナ上で稼働するアプリの脆弱性/NIST 3.4.4）
4.5 Rogue containers（許可されていないコンテナの実行/NIST 3.4.5）
ホストOSのリスク 5.1 Large attack surface（コンテナ、他ホストへの侵害/NIST 3.5.1）
5.2 Shared kernel（コンテナとホストのカーネル共有による侵害/NIST 3.5.2）
5.3 Host OS component vulnerabilities（ホストOSコンポーネントの脆弱性/NIST 3.5.3）
5.4 Improper user access rights（不適切なユーザアクセス権/NIST 3.5.4）
5.5 Host OS file system tampering（ホストOSファイルシステムの改ざん/NIST 3.5.5）

要素考慮ポイント
Pod ・PodSecurityContextの設定
・PodSecurityPolicyによる制限
・NetworkPolicyによる通信ポリシー設定
・RBACによるAPIアクセス制限
Node ・Taint/Tolerationによるノードの分離
・NodeAffinity
・NodeRestriction
Namespace ・RBACによるAPIアクセス制限（Namespaceレベル）
・ResourceQuota
Cluster ・RBACによるAPIアクセス制限（クラスタレベル）
・etcdの暗号化
・システムコンポーネント間の通信暗号化

（参考）RBACとは
ロール商用環境データ開発環境データ開発中プログラム
インフラ担当〇〇 ×
アプリケーション開発担当 × 〇〇
運用担当〇 × ×
システム開発におけるRBACの例
• Role Based Access Control（ロールベースアクセス制御）の略称
• 役職や組織、役割などのロール単位にアクセス制御を行う考え方
• KubernetesだけでなくクラウドサービスやSaaS、業務システムにて広く使われるもの

（参考）KubernetesAPIへのアクセスの制御
• KubenernetesAPIのアクセス制御は下図の通り
• RBACは「Authorization（認可）」での制御を管理するもの
RBAC

RBAC制御のためのリソース
• Role/ClusterRole
• Kubernetesリソースへの権限を規定するリソース
• Role：特定範囲（Namespace）での独自定義
• ClusterRole：クラスタ全体で利用可能な共通定義
• Role Binding/Cluster Role Binding
• Role/ClusterRoleとユーザーを紐づけるためのリソース
• どちらで紐づけるかにより権限の適用範囲が変わる
User Role A
Role Binding
ClusterRole A
ClusterRole B
ClusterRole
Binding
SA
create
list
delete
get
get

• デフォルトで以下のClusterRoleが用意されている
ClusterRole 説明利用者例
cluster-admin 全てのリソースに対しあらゆる権限を持つ。クラスタ管理者
admin
Namespace内のほとんどのリソースの編集権限を有する。Role/RoleBinding
の編集も可。ただしLimitrange、ResourceQuota、Namespace、
PodSequrityPolicyなどのクラスタリソースの編集は不可。
Namespace管理者
Namespaceで稼働するシステム
edit Role/RoleBindingなど一部のリソースを除き、参照/編集が可能。アプリケーション開発者
view リソースの参照のみ可能。（Role/RoleBinding、Secretの参照は不可。）テスター、監視オペレータ

• 紐づけ方により適用範囲が変わる
権限紐づけ適用範囲
Role RoleBinding 単一のNamespace
Role ClusterRoleBinding 紐づけ不可
ClusterRole RoleBinding 単一Namespace
ClusterRole ClusterRoleBinding
クラスタ
（≒全てのNamespace）

クラスタ
わかるけどわからん。

クラスタ
例えば、Role×RoleBindingとClusterRole×RoleBinding
はいずれもNamespaceの範囲に適用されるもの。
どう使い分けたらいいの？

設計例：例えば、、
• インフラチーム
• クラスタ管理者。クラスタ全体の運用・管理作業を実施。
• Webアプリチーム、バッチアプリチーム
• 各アプリケーションのチームの範囲でアプリケーションのデプロイやテストを実施。
• アプリチームには管理者・テスターが存在。
• Webアプリのテスターは参照権限を最低限としたい。
• セキュリティ監査チーム
• クラスタ全体に対し、セキュリティ監査のためにリソースやログの確認を実施。

Namespace（web）
Namespace（batch）
Kubernetes Cluster
Clustradmin
view
admin
Web-view
edit
インフラ管理
セキュリティ監査
バッチ：テスター
バッチ：管理者
Web：管理者
Web：テスター

Namespace（web）
Kubernetes Cluster
Clustradmin
view
admin
Web-view
edit
インフラ管理
Web：管理者
Web：テスター
クラスタ全体（共通定義）
リソース

Namespace（web）
Kubernetes Cluster
Clustradmin
view
admin
Web-view
edit
インフラ管理
Web：管理者
Web：テスター
クラスタ全体（共通定義）
リソース
Nanaspace内（独自定義）
リソース

設計通りに実装できているか確認したい
この実装でよいのだろうか？
定義ファイル（マニフェスト）を直接確認したり
標準コマンドだけでは大変、、、
実装後、、

RBACの可視化・メンテナンス
• rbac tool
• kubectlのプラグインとして利用可能
• rbac-tool viz
• クラスタのRBACを可視化。
• ユーザ、ロール、リソースの関係の全体像を把握できる。
• rbac-tool analysis
• RBACを分析し、注意すべき権限についてアラートを出力。
• 過度な権限がついていないかの確認に役立つ。
• rbac-tool policy-rules
• 特定のロール、ユーザの権限をリストで出力する。

rbac-tool viz
• ユーザ、ロール、リソースの関係を視覚的に確認できる。

rbac-tool analysis
• RBACを分析し、過剰な権限付与が行われている懸念があったり、注意すべき権限についてアラート
を出力してくれる
• 検出は一定のルールに基づいて実施される
https://github.com/alcideio/rbac-tool/blob/master/pkg/analysis/default-rules.yaml
ルール：Secret Readersで検知された例

rbac-tool policy-rules
• 特定のロール、ユーザの権限をリストで出力する。
「dev-web」グループに付与された権限のリストの確認例

RBACの可視化・メンテナンス
• 見直し方の例
• リソース単位
• 例：networkpolicy、service、ingressなど通信に関わるリソースは編集不可とする
• アクション（verb）単位
• 例：参照系のみ許可し編集系は不可
• 共通化、独自ロールへの切り出し

（参考）PCIDSSへの適用
• PCIDSS：クレジットカード業界で策定されたセキュリティ基準
• RBAC設計及び管理ルールの策定・運用により以下の要件に適用可能
1. 安全なネットワークとシステムの構築と維持 1. カード会員データを保護するために、ファイアウォールをインストールして維持する
2. システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
2. カード会員データの保護 3. 保存されるカード会員データを保護する
4. オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
3. 脆弱性管理プログラムの維持 5. マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する
6. 安全性の高いシステムとアプリケーションを開発し、保守する
4. 強力なアクセス制御手法の導入 7. カード会員データへのアクセスを、業務上必要な範囲内に制限する
8. システムコンポーネントへのアクセスを識別・認証する
9. カード会員データへの物理アクセスを制限する
5. ネットワークの定期的な監視およびテスト 10. ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
11. セキュリティシステムおよびプロセスを定期的にテストする
6. 情報セキュリティポリシーの維持 12. すべての担当者の情報セキュリティに対応するポリシーを維持する

fin
＊記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です。

KubernetesのRBACを掘り下げてみる（Kubernetes Novice Tokyo #17 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to KubernetesのRBACを掘り下げてみる（Kubernetes Novice Tokyo #17 発表資料）

Similar to KubernetesのRBACを掘り下げてみる（Kubernetes Novice Tokyo #17 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (14)

KubernetesのRBACを掘り下げてみる（Kubernetes Novice Tokyo #17 発表資料）

Editor's Notes