Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
container.clusters.getこの権限は、次のような方法でKubernetesクラスターの資格情報を収集することを許可します：
追加の権限がなくても、資格情報は非常に基本的で、いくつかのリソースをリストすることができるが、環境内の誤設定を見つけるのに役立ちます。
Kubernetesクラスターはプライベートに設定されている可能性があるため、インターネットからKube-APIサーバーへのアクセスが禁止されます。
この権限がない場合でもクラスターにアクセスできますが、クラスターの情報を含む独自のkubectl設定ファイルを作成する必要があります。新しく生成されたものは次のようになります：
container.roles.escalate | container.clusterRoles.escalateKubernetes はデフォルトで、プリンシパルが自分が持っている権限よりも 多くの権限 を持つ Roles と ClusterRoles を 作成 または 更新 できないように 防止 します。しかし、権限を持つ GCP プリンシパルは、自分が持っている権限よりも 多くの権限 を持つ Roles/ClusterRoles を 作成/更新 でき、実質的にこの動作に対する Kubernetes の保護を回避します。
container.roles.create および/または container.roles.update または container.clusterRoles.create および/または container.clusterRoles.update は、それらの特権昇格アクションを実行するために 必要 です。
container.roles.bind | container.clusterRoles.bindKubernetes はデフォルトで、プリンシパルが自分が持っている権限よりも 多くの権限 を与える RoleBindings と ClusterRoleBindings を 作成 または 更新 できないように 防止 します。しかし、権限を持つ GCP プリンシパルは、自分が持っている権限よりも 多くの権限 を持つ RolesBindings/ClusterRolesBindings を 作成/更新 でき、実質的にこの動作に対する Kubernetes の保護を回避します。
container.roleBindings.create および/または container.roleBindings.update または container.clusterRoleBindings.create および/または container.clusterRoleBindings.update は、それらの特権昇格アクションを実行するために 必要 です。
container.cronJobs.create | container.cronJobs.update | container.daemonSets.create | container.daemonSets.update | container.deployments.create | container.deployments.update | container.jobs.create | container.jobs.update | container.pods.create | container.pods.update | container.replicaSets.create | container.replicaSets.update | container.replicationControllers.create | container.replicationControllers.update | container.scheduledJobs.create | container.scheduledJobs.update | container.statefulSets.create | container.statefulSets.updateこれらのすべての権限は、リソースを作成または更新 することを可能にし、そこで pod を 定義 できます。pod を定義することで、SA を 添付 し、実行する イメージ を指定できるため、SA のトークンをあなたのサーバーに外部流出させる イメージを実行することができ、任意のサービスアカウントに昇格できます。 詳細については、次を確認してください：
GCP 環境にいるため、メタデータ サービスから ノードプール GCP SA を 取得 し、GCP で特権を昇格させることもできます（デフォルトではコンピュート SA が使用されます）。
container.secrets.get | container.secrets.listこのページで説明されているように、これらの権限を使用すると、すべての Kubernetes の SA のトークン を 読み取る ことができるため、それらに昇格できます。
container.pods.execこの権限を持つことで、pod に exec でき、Kubernetes の SA に アクセス して K8s 内で特権を昇格させることができますが、NodePool の GCP サービスアカウント を 盗む こともでき、GCP で特権を昇格させることができます。
container.pods.portForwardこのページで説明されているように、これらの権限を使用すると、pod で実行されている ローカルサービス に アクセス でき、Kubernetes で特権を昇格させることができるかもしれません（そして、何らかの方法でメタデータサービスにアクセスできれば GCP でも）。
container.serviceAccounts.createToken権限の名前 から判断すると、K8s サービスアカウントのトークンを生成することを許可する ように見え、Kubernetes 内の任意の SA に 特権昇格 できるようになります。しかし、使用する API エンドポイントを見つけることができなかったので、見つけたら教えてください。
container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.updateこれらの権限は、Kubernetes で特権を昇格させることを可能にするかもしれませんが、より可能性が高いのは、クラスターに持続する ためにそれらを悪用できることです。 詳細については、このリンクをフォロー。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
