Kubernetes Role-Based Access Control(RBAC)

HackTricks をサポートして特典を得る！

HackTricks で会社を宣伝したい場合や、最新バージョンの PEASS を見たい場合、または HackTricks を PDF でダウンロードしたい場合は、SUBSCRIPTION PLANS をチェックしてください！
公式の PEASS & HackTricks スワッグ を手に入れましょう
The PEASS Family を見つけて、独占的な NFT のコレクションを見つけましょう
💬 Discord グループ または telegram グループ に参加するか、Twitter 🐦 @carlospolopm をフォローしましょう。
ハッキングのトリックを共有するには、 HackTricks と HackTricks Cloud の GitHub リポジトリに PR を提出してください。

ロールベースのアクセス制御（RBAC）

Kubernetes には、API サーバーに利用権限を設定するのに役立つ ロールベースのアクセス制御（RBAC） という 認可モジュール があります。

RBAC の権限モデルは、3 つの個別のパーツ から構築されています：

ロール/クラスターロール - 実際の権限です。これには、一連の権限を表す ルール が含まれています。各ルールには、リソースと動詞が含まれています。動詞は、リソースに適用されるアクションです。
サブジェクト（ユーザー、グループ、またはサービスアカウント） - 権限を受け取るオブジェクトです。
ロールバインディング/クラスターロールバインディング - ロール/クラスターロールとサブジェクトの接続です。

「ロール」と「クラスターロール」の違いは、ロールが適用される場所だけです - 「ロール」は 1 つの特定のネームスペース にのみアクセス権限を付与しますが、「クラスターロール」はクラスタ内の すべてのネームスペース で使用できます。さらに、クラスターロール は次のものにもアクセス権限を付与できます：

クラスタ全体のリソース（ノードなど）。
非リソースエンドポイント（/healthz など）。
ネームスペース内のリソース（Pod など）、すべてのネームスペース を対象とします。

Kubernetes 1.6 以降、RBAC ポリシーはデフォルトで有効になっています。ただし、RBAC を有効にするには、次のような方法を使用できます：

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

テンプレート

RoleまたはClusterRoleのテンプレートでは、ロールの名前、名前空間（ロールの場合）、そしてロールのapiGroups、resources、verbsを指定する必要があります。

apiGroupsは、このルールが適用されるAPI名前空間を含む配列です。たとえば、Podの定義ではapiVersion: v1を使用します。rbac.authorization.k8s.ioや[*]などの値を持つことができます。
resourcesは、このルールが適用されるリソースを定義する配列です。すべてのリソースはkubectl api-resources --namespaced=trueで確認できます。
verbsは、許可される動詞を含む配列です。Kubernetesの動詞は、リソースに適用する必要のあるアクションのタイプを定義します。たとえば、list動詞はコレクションに対して使用され、"get"は単一のリソースに対して使用されます。

ルールの動詞

(この情報は こちら から取得されました)

HTTP動詞	リクエスト動詞
POST	create
GET, HEAD	get（個々のリソースに対して）、list（コレクションに対して、オブジェクトの内容を含む）、watch（個々のリソースまたはリソースのコレクションを監視するため）
PUT	update
PATCH	patch
DELETE	delete（個々のリソースに対して）、deletecollection（コレクションに対して）

HTTP動詞

リクエスト動詞

POST

create

GET, HEAD

get（個々のリソースに対して）、list（コレクションに対して、オブジェクトの内容を含む）、watch（個々のリソースまたはリソースのコレクションを監視するため）

PUT

update

PATCH

patch

DELETE

delete（個々のリソースに対して）、deletecollection（コレクションに対して）

Kubernetesは、特殊な動詞を使用して追加の権限の認可をチェックすることがあります。たとえば：

PodSecurityPolicy
policy APIグループのpodsecuritypoliciesリソースでuse動詞を使用します。
RBAC
rbac.authorization.k8s.io APIグループのrolesおよびclusterrolesリソースでbindおよびescalate動詞を使用します。
Authentication
コアAPIグループのusers、groups、serviceaccountsおよびauthentication.k8s.io APIグループのuserextrasでimpersonate動詞を使用します。

kubectl api-resources --sort-by name -o wideを実行して、各リソースがサポートするすべての動詞を見つけることができます。

例

Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

例えば、特定のユーザーが実行できるようにするために、ClusterRoleを使用することができます。

kubectl get pods --all-namespaces

RoleBindingとClusterRoleBinding

RoleBindingは、ユーザーまたはユーザーセットに定義された権限を付与します。それはサブジェクト（ユーザー、グループ、またはサービスアカウント）のリストと、付与される役割への参照を保持します。RoleBindingは特定のネームスペース内で権限を付与しますが、ClusterRoleBindingはクラスタ全体でアクセスを付与します。

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

権限は加算されますので、"list"と"delete"のシークレットを持つclusterRoleを持っている場合、それを"get"を持つRoleで追加することができます。したがって、常に役割と権限をテストし、許可されているものを明示してください。なぜなら、デフォルトではすべてが拒否されるからです。

RBACの列挙

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

特権昇格のための役割/クラスターロールの悪用

pageAbusing Roles/ClusterRoles in Kubernetes

ハックトリックをサポートして特典を得る！

HackTricksであなたの会社を宣伝したい場合や、PEASSの最新バージョンを入手したい場合は、SUBSCRIPTION PLANSをチェックしてください！
公式PEASS＆HackTricksグッズを手に入れる
The PEASS Familyを見つけて、独占的なNFTのコレクションを発見する
💬 DiscordグループまたはTelegramグループに参加するか、Twitterで私をフォローする 🐦 @carlospolopm
ハッキングのトリックを共有するには、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

前へKubernetes Enumeration 次へAbusing Roles/ClusterRoles in Kubernetes

最終更新 10 か月前