POD 中的 configMap 引用是否需要 ServiceAccount？

Question

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

样品POD Yaml安装配置图

    - 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

几个Q

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

Answer 1

访问 configMap 是否需要适当的 ServiceAccount 以及专门为 configMap 访问指定的访问规则？

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

如果一个对象只能由有限的一组用户访问，则应该在角色级别发生，以防止用户调度接触敏感项目的 Pod。

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

据我所知，一切都受 RBAC 规则的约束，即使它们不令您满意，系统也提供验证准入控制器，允许极其细粒度的访问规则