首先,区分对机密的API访问和将机密作为环境变量或装入的卷使用是很重要的。

TLDR:

• RBAC控制谁可以使用K8s API请求访问机密(或任何其他资源)。
• 命名空间或服务帐户的 secrets 属性控制如果pod可以将机密作为环境变量或通过卷装载来使用。

RBAC用于控制身份(在您的示例中是服务帐户)是否允许通过K8s API访问资源。您可以通过创建一个RoleBinding(namespaced)或一个ClusterRoleBinding(集群范围),将一个标识绑定到一个角色(namespaced)或一个ClusterRole(非namespaced)绑定到您的标识(服务帐户)。然后,当您通过设置 serviceAccountName 属性,在该pod中运行kubectl get secret或从其中一个客户机库中运行等效方法意味着您拥有发出API请求的凭据。

消费秘密

但是,这与配置pod以将机密作为环境变量或卷装载使用无关。如果pod spec中的容器规范引用了该机密,那么它将在该容器中可用。注意,每个集装箱,而不是每个吊舱。您可以通过在不同的名称空间中使用pod来限制pod可以装载的秘密,因为pod只能引用同一名称空间中的机密。此外,您可以使用服务帐户的 秘密 属性,以限制具有thet服务帐户的pod可以引用的机密。

$ kubectl explain sa.secrets
KIND:     ServiceAccount
VERSION:  v1

RESOURCE: secrets <[]Object>

DESCRIPTION:
     Secrets is the list of secrets allowed to be used by pods running using
     this ServiceAccount. More info:
     https://kubernetes.io/docs/concepts/configuration/secret

     ObjectReference contains enough information to let you inspect or modify
     the referred object.

您可以在 secret documentation

其思想是将对用户服务机密机密的访问限制为分配给用户服务Pod的用户服务服务帐户。因此,我们可以使用相关的Kubernetes资源(即ServiceAccount、Role、RoleBinding)来设置这一切,但是我们意识到了这一点 这可能实际上没有强制执行 ,因为 事务服务舱可以很容易地读取用户的服务秘密 当Pod启动时,即使其分配给的服务帐户没有获取用户服务机密的权限。

是的,这是正确的。

Bernkuetes对此有记载 privilege escalation via pod creation 命名空间 .

能够在命名空间中创建pod的用户可能会提升其在该命名空间中的权限。他们可以创建在该命名空间中访问其特权的pod。它们可以创建访问用户自己无法读取的机密的pod,或者在具有不同/更大权限的服务帐户下运行的pod。

实际上 执行 入口控制器 Open Policy Agent