Kubernetes RBAC 101: ヘルパーコマンドを使用してセキュリティ制御を強化する方法

今日は、クラスターのセキュリティ制御を強化するために不可欠な、重要でありながらあまり知られていない補助コマンドをいくつか探りながら、Kubernetes の世界を深く掘り下げていきます。 RBAC ポリシーをより効果的に理解して管理し、Kubernetes 環境のセキュリティを確保するのに役立つこれらのツールについて詳しく紹介します。

初期準備

開始する前に、開発者が必要なリソースを使用および構成できるように、クラスター内に名前空間 developer を作成します。これらの手順には、名前空間、サービス アカウント、サービス アカウント キー (トークン) の作成、特定のロールとロール バインディングの定義が含まれます。

 # 1. 创建namespace kubectl create ns developer # 2. 创建ServiceAccount kubectl -n developer create serviceaccount owner # 3. 创建服务账号token 类型的secret cat << EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: owner-secret namespace: developer annotations: kubernetes.io/service-account.name: owner type: kubernetes.io/service-account-token EOF # 4. 创建角色kubectl create role Owner \ --resource pods,services,endpoints,secrets \ --verb get,list,watch \ -n developer # 5. 将这个Owner 角色的权限授予服务账号developer:owner kubectl create rolebinding owner-binding \ --role=Owner \ --serviceaccount=developer:owner \ -n developer

kubectl 認証はできる

kubectl auth can-i は、ユーザーまたはサービス アカウントに特定の Kubernetes 操作を実行する権限があるかどうかを確認するための便利な権限チェック ツールです。

たとえば、初期化フェーズ中に Pod を作成する権限が正しく制限されていることを確認できます。

 ➜ kubectl --kubeconfig dev-config auth can-i create pod no

同様に、ユーザーは次のコマンドを実行して、現在の名前空間内のすべての操作を実行する権限があるかどうかを確認することもできます。

 ➜ kubectl --kubeconfig dev-config auth can-i '*''*' no

管理者は、--as パラメータを使用して任意のサービス アカウントの権限を偽装し、権限設定をさらに検査することもできます。

 ➜ kubectl auth can-i \ get pods --as=system:serviceaccount:developer:owner -n developer yes ➜ kubectl auth can-i \ create pod --as=system:serviceaccount:developer:owner -n developer no

制限

kubectl auth は便利ですが、複雑なクエリをサポートしておらず、権限の完全なビューも提供しません。

クラスター管理者として、リソースに対して特定の操作を誰が実行しているかを知りたい場合は、さらに困難になります 🤦

kubectl できる人

kubectl-who-can[1]はKubernetesのネイティブ機能を拡張し、RBACポリシーの詳細な分析を提供する高度なツールであり、管理者と開発者が特定の操作を実行する権限を持つユーザーを迅速に把握するのに役立ちます。

これは主に、特定のリソースに対して指定されたアクション (作成、取得、削除など) を実行する権限を持つサブジェクト (ユーザー、グループ、サービス アカウントなど) を示すために使用されます。これは、既存の RBAC 構成を分析することによって実現されます。

インストール

Krew を通じて非常に簡単にインストールできます。

 kubectl krew install who-can

使い方は？

たとえば、特定の名前空間内の Pod を取得する権限を持つユーザーまたはサービス アカウントを確認するには、次のコマンドを実行します。

 ➜ kubectl who-can get pods -n developer ROLEBINDING NAMESPACE SUBJECT TYPE SA-NAMESPACE owner-binding developer owner ServiceAccount developer CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group system:kube-scheduler system:kube-scheduler User system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:endpointslice-controller endpointslice-controller ServiceAccount kube-system system:controller:ephemeral-volume-controller ephemeral-volume-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system k3s-cloud-controller-manager k3s-cloud-controller-manager User kube-system local-path-provisioner-bind local-path-provisioner-service-account ServiceAccount kube-system system:k3s-controller system:k3s-controller User cert-manager-controller-challenges cert-manager ServiceAccount cert-manager xfs2-csi-driver xfs2-csi-driver-controller-sa ServiceAccount xfs2-csi-driver

このコマンドは、開発者名前空間 (名前空間レベルとクラスター レベルの両方) で Pod を取得する権限を持つすべてのプリンシパルを一覧表示します。これは、権限の監査、セキュリティ レポートの準備、トラブルシューティングに役立ちます。

kubectl-who-canの利点

1. 詳細な権限分析: K8s に付属する kubectl auth can-i と比較すると、kubectl-who-can はより包括的な視点を提供し、権限があるかどうかだけでなく、クラスター内の誰がこれらの権限を持っているかも示します。
2. セキュリティ監査: このツールは、権限の過剰割り当ての可能性を迅速に特定するのに役立つため、セキュリティ チームにとって特に重要です。
3. トラブルシューティングの簡素化: 権限の問題をデバッグするときに、特定のアクションを実行する権限を持つすべてのエンティティをすばやく識別できると、問題解決プロセスが大幅に簡素化されます。

制限

kubectl-who-can は権限管理とセキュリティ監査に非常に効果的ですが、その出力は現在の RBAC 構成のみに基づいています。

kubectl-ロールサム

次に、ロールとロールバインディングを明確に表示する非常に便利なサードパーティツールであるkubectl-rolesum[2]について説明します。

その主な機能は、特定の K8s エンティティ (ユーザー、グループ、サービス アカウントなど) のロール権限を集約して表示することであり、これはセキュリティ ポリシーの検証とトラブルシューティングに非常に重要です。

インストール

Krew を通じて非常に簡単にインストールできます。

 kubectl krew install rolesum

使い方は？

上記のユースケースに戻ると、次のコマンドは、標準の kubectl コマンドよりも詳細で直感的な権限ビューを提供できます。

 ➜ kubectl rolesum owner -n developer ServiceAccount: developer/owner Secrets: Policies: • [RB] developer/owner-binding ⟶ [R] developer/Owner Resource Name Exclude Verbs GLWCUPD DC endpoints [*] [-] [-] ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖ pods [*] [-] [-] ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖ secrets [*] [-] [-] ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖ services [*] [-] [-] ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖

いくつかのフィールドの説明は次のとおりです。

• RB: ロールバインディング
• R: 役割
• CRB: クラスターロールバインディング
• CR: クラスターロール
• G: ゲット
• L: リスト
• W: 時計
• C: 作成
• U: 更新
• P: パッチ
• D: 削除
• DC: コレクションの削除

実践事例

以下は実際のアプリケーションケースのスクリーンショットです。このサービスにどのような権限が付与されているかが明確にわかります。

写真

実際の開発プロセスで、一部のリソースが作成できない、またはその他の権限が異常であることがわかった場合、このツールを通じてすぐに原因を突き止めることができます。

また、権限の現在のステータスをすぐに示すことができるため、監査やコンプライアンス チェックにも役立つツールです。

制限

kubectl-rolesum の主な利点は、標準の kubectl コマンドよりも詳細で直感的な権限ビューを提供することです。これは、複雑な RBAC ポリシーを管理する場合に特に役立ちます。

ただし、制限もあり、これらのロールを作成または変更する機能は提供されません。

rbac ツール

最後に、RBACポリシーのクエリを簡素化するだけでなく、これらのポリシーをより簡単に作成および管理するのに役立つ強力で多用途なツールであるrbac-tool[3]について説明します。

インストール

Krew を通じて非常に簡単にインストールできます。

 kubectl krew install rbac-tool

使い方は？

たとえば、特定の名前空間またはクラスター全体の RBAC 権限グラフを生成するには、次のコマンドを使用できます。

 kubectl rbac-tool viz --outformat dot \ && cat rbac.dot | dot -Tpng > rbac.png && open rbac.png

このコマンドは、Graphviz などのグラフィカル ツールで開いて、ロールとロール バインディングの関係のグラフを表示できる DOT ファイルを作成します。

前の例の場合、次のコマンドを使用して Chrome で開き、所有者のステータスを表示することもできます。

 ➜ kubectl rbac-tool viz --include-subjects=owner && open -a "Google Chrome" rbac.html [RAPID7-INSIGHTCLOUDSEC] Namespaces included '*' [RAPID7-INSIGHTCLOUDSEC] Namespaces excluded 'kube-system' [RAPID7-INSIGHTCLOUDSEC] Connecting to cluster '' [RAPID7-INSIGHTCLOUDSEC] Generating Graph and Saving as 'rbac.html'

効果は以下のとおりです。

写真

kubectl rbac-tool ルックアップ

プリンシパルを照会するための権限を提供します:

 ➜ kubectl rbac-tool lookup -e '^owner.*' SUBJECT | SUBJECT TYPE | SCOPE | NAMESPACE | ROLE +---------+----------------+-------+-----------+-------+ owner | ServiceAccount | Role | developer | Owner

rbac ツール 誰ができる

kubectl-who-can の機能と同様に、特定の操作を実行する権限を持つユーザーを確認します。

 ➜ kubectl rbac-tool who-can get pod TYPE | SUBJECT | NAMESPACE +----------------+----------------------------------------+------------------------------------------------+ Group | system:masters | ServiceAccount | cert-manager | cert-manager ServiceAccount | deployment-controller | kube-system ServiceAccount | endpoint-controller | kube-system ServiceAccount | endpointslice-controller | kube-system ServiceAccount | ephemeral-volume-controller | kube-system ServiceAccount | generic-garbage-collector | kube-system ServiceAccount | local-path-provisioner-service-account | kube-system ServiceAccount | namespace-controller | kube-system ServiceAccount | node-controller | kube-system ServiceAccount | owner | developer ServiceAccount | persistent-volume-binder | kube-system ServiceAccount | pvc-protection-controller | kube-system ServiceAccount | statefulset-controller | kube-system ServiceAccount | user-sa | user-zone-4ef1aab6-3c45-4d37-bdb1-0b0c629b3b26 ServiceAccount | user-sa | user-zone-729281f1-46e8-4d63-8ab8-cfd895923bab ServiceAccount | xfs2-csi-driver-controller-sa | xfs2-csi-driver User | k3s-cloud-controller-manager | kube-system User | system:k3s-controller | User | system:kube-scheduler |

rbac ツール ポリシー ルール

kubectl-rolesum の機能と同様に詳細な権限ルールを表示しますが、出力の視覚化に関しては、kubectl-rolesum の方が明確だと思います。

 ➜ kubectl rbac-tool policy-rules -e '^owner' TYPE | SUBJECT | VERBS | NAMESPACE | API GROUP | KIND | NAMES | NONRESOURCEURI | ORIGINATED FROM +----------------+---------+-------+-----------+-----------+-----------+-------+----------------+-------------------------+ ServiceAccount | owner | get | developer | core | endpoints | | | Roles>>developer/Owner ServiceAccount | owner | get | developer | core | pods | | | Roles>>developer/Owner ServiceAccount | owner | get | developer | core | secrets | | | Roles>>developer/Owner ServiceAccount | owner | get | developer | core | services | | | Roles>>developer/Owner ServiceAccount | owner | list | developer | core | endpoints | | | Roles>>developer/Owner ServiceAccount | owner | list | developer | core | pods | | | Roles>>developer/Owner ServiceAccount | owner | list | developer | core | secrets | | | Roles>>developer/Owner ServiceAccount | owner | list | developer | core | services | | | Roles>>developer/Owner ServiceAccount | owner | watch | developer | core | endpoints | | | Roles>>developer/Owner ServiceAccount | owner | watch | developer | core | pods | | | Roles>>developer/Owner ServiceAccount | owner | watch | developer | core | secrets | | | Roles>>developer/Owner ServiceAccount | owner | watch | developer | core | services | | | Roles>>developer/Owner

私は以前rakkess[4]を使ったことがありますが、これもリソースアクセスマトリックスの点で非常に使いやすいです。

写真

rbac ツール gen

カスタム RBAC ルールを生成します。 kubectl create role および kubectl create clusterrole に似ていますが、リソース仕様の点でいくつかのシナリオではより柔軟で効率的です。

 ➜ kubectl rbac-tool gen \ --generated-type=Role \ --allowed-verbs=get,list,watch \ --allowed-groups=, \ --deny-resources=bindings.,persistentvolumeclaims.,limitranges.,events.,replicationcontrollers.,configmaps.,resourcequotas.,podtemplates.,serviceaccounts. apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: custom-role namespace: mynamespace rules: - apiGroups: - "" resources: - pods - secrets - endpoints - services verbs: - get - list - watch

比較すると、rbac-tool は RBAC 管理において依然として非常に強力です。

学んだことを実践する

前の章では、Kubernetes の RBAC ツールとコマンドを詳しく調べ、それらを使用してセキュリティ監査を実行したり、トラブルシューティングを簡素化したりする方法を学びました。しかし、ツールを持っているだけでは安全を確保するのに十分ではありません。これらのツールを正しく効率的に適用することも同様に重要です。したがって、次のセクションでは、「RBAC ベスト プラクティス」に関するいくつかの重要な戦略と推奨事項を紹介します。

1. 最小権限の原則

役割を定義するときは、最小権限の原則に従う必要があります。不正なアクションのリスクを最小限に抑えるために、特定のタスクを実行するために必要な最小限の権限のみを付与します。これは安全を確保するための重要なステップです。

2. 定期的な監査

クラスター内の RBAC 構成を定期的に確認および監査し、組織のセキュリティ ポリシーと一致していることを確認します。不要な権限や過剰な権限を削除し、必要に応じてロールを更新します。これにより、明確で安全な権限構造を維持できます。

3. 名前空間を効果的に使用する

名前空間を活用して、さまざまなチームまたはプロジェクトを論理的に分離し、名前空間レベルで RBAC ポリシーを適用します。これにより、権限の管理がより効率的になり、異なるチームやプロジェクト間の運用の分離が保証されます。

4. RBACポリシーをテストする

当社では、RBAC ポリシーを本番環境クラスターに適用する前に、非本番環境で徹底的にテストし、期待どおりに動作することを確認しています。これは、潜在的な問題が実稼働環境に影響するのを防ぐための重要なステップです。

結論

これらの強力なツールを調べることで、Kubernetes RBAC 管理に対する理解が深まっただけでなく、クラスターのセキュリティ強化に関する新たな視点も得られました。 kubectl auth can-i の基本的な権限チェックから、kubectl-who-can の詳細な分析、kubectl-rolesum と rbac-tool の包括的なビューまで、これらのツールを組み合わせることで、より透明性が高く堅牢な Kubernetes 環境が構築されます。

Kubernetes のセキュリティは継続的な取り組みであることを忘れないでください。これらのツールと継続的な学習により、クラスターが強力かつ安全であることを保証できます。