Kubernetes合并多API组Role规则时YAML解析报错问题

一、YAML解析错误的原因 #

你遇到的did not find expected key错误，基本是合并YAML时的缩进错误或者规则结构混乱导致的。比如你可能把两个不同API组的配置强行塞到同一个rule条目里，或者缩进层级不对（比如某个字段没有对齐到正确层级，导致YAML解析器无法识别合法的键）。举两个典型错误场景：

# 错误写法1：强行合并API组导致后续权限问题，若缩进失误也会触发解析错误
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-role
rules:
- apiGroups: ["", "apps"]
  resources: ["namespaces", "configmaps", "deployments"]
  verbs: ["get", "watch", "list"]

# 错误写法2：缩进层级错误直接触发解析失败
- apiGroups: [""]
  resources: ["namespaces", "configmaps"]
    verbs: ["get", "watch", "list"] # verbs缩进多了一级，解析器找不到对应键

二、合并多API组规则的正确方式 #

Kubernetes的Role资源中，rules是一个数组，每个数组元素是独立的权限规则条目。正确做法是为不同API组分别定义独立的rule对象，各自指定对应的apiGroups、resources和verbs，示例如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-role
rules:
# 空API组（核心API组）的资源规则
- apiGroups: [""]
  resources: ["namespaces", "configmaps", "secrets"]
  verbs: ["get", "watch", "list"]
# apps API组的资源规则
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "watch", "list"]

这种写法既符合YAML语法规范，又能精准区分不同API组的资源：每个规则条目只负责对应API组下的资源，不会让OpenShift去检查apps组是否存在namespaces这类不属于它的资源，自然避免了非集群管理员的权限错误。

补充说明 #

为什么不能把apiGroups设为["", "apps"]？因为Kubernetes权限检查逻辑是：指定多个API组时，会对每个API组验证你列出的资源是否存在。而namespaces、configmaps仅属于空API组，apps组根本没有这些资源，非集群管理员用户没有权限查询apps组中不存在的资源，因此会触发权限错误。

内容的提问来源于stack exchange，提问作者adam sranko