POD 中的 configMap 引用不需要 ServiceAccount 吗？

问题描述

好奇如何在没有适当 serviceAccount 和相关 RBAC 规则的情况下在 POD 中引用 configMaps？

示例 POD Yaml 挂载 configMap

    - mountPath: /kubernetes-vault
      name: kubernetes-vault

       .................
       .................

          volumes:
      - emptyDir: {}
        name: vault-token
      - configMap:
          defaultMode: 420
          name: kubernetes-vault
    name: kubernetes-vault

但是 associated ServiceAccount and it's corresponding RBAC ( Role and RoleBinding ) 没有任何规则指定此 configMap (kubernetes-vault) 的访问规则

POD 的角色和规则

rules:
- apiGroups:
  - '*'
  resources:
  - services
  - pods
  - endpoints
  verbs:
  - get
  - list
  - watch

几个问题

对 configMap 的访问是否需要适当的 ServiceAccount，并具有专门为 configMap 访问指定的访问规则？
如果是，上面提到的哪个规则管理 configMap 访问
如果不是，哪些对象受 RBAC 规则的约束？

解决方法

访问 configMap 是否需要适当的 ServiceAccount，并具有专门为 configMap 访问指定的访问规则？

当 ServiceAccount 正在执行该操作时，是的，但是 volumes: 是由 kube-apiserver、kube-controller 和与之交互的调用凭据的混合执行的apiserver。到 Pod 的卷挂载时，所有这些安全检查都已完成——您可以通过运行任何 Pod 并抑制其 ServiceAccount 来验证该行为，并观察卷挂载仍在发生

如果一个对象只应由有限的一组用户访问，则应在角色级别发生这种情况，以防止用户安排接触敏感项目的 Pod。

如果不是，哪些对象受 RBAC 规则的约束？

据我所知，一切都受 RBAC 规则的约束，即使它们不让您满意，系统也提供了 Validating Admission Controllers 允许 非常强>细粒度的访问规则

configmap kubernetes