【问题标题】：How is Kubernetes RBAC Actually Enforced for Service Accounts?Kubernetes RBAC 是如何对服务账户实施的？
【发布时间】：2020-11-17 00:50:05
【问题描述】：

我们正在尝试创建不同的 kuberentes 机密，并通过分配给 pod 的特定服务帐户提供对特定机密的访问。例如：

秘密

- User-Service-Secret
- Transaction-Service-Secret

服务帐号

- User-Service
- Transaction-Service

豆荚

- User-Service-Pod
- Transaction-Service-Pod

这个想法是将User-Service-Secretsecret 的访问限制为分配给User-Service-Pod 的User-Service 服务帐户。所以我们可以使用相关的 kuberentes 资源（即 ServiceAccount、Role、RoleBinding）来设置这一切，但我们意识到这可能实际上并没有强制执行，因为 Transaction-Service-Pod 可以在 Pod 启动时轻松读取 User-Service-Secret 秘密，即使它分配给的服务帐户没有get 对User-Service-Secret 的权限。

我们如何实际执行 RBAC 系统？

仅供参考，我们正在使用 EKS

【问题讨论】：

标签： kubernetes amazon-eks

【解决方案1】：

首先，重要的是区分 API 访问密钥和将密钥作为环境变量或挂载卷使用。

TLDR：

RBAC 控制谁可以使用 K8s API 请求访问机密（或任何其他资源）。
命名空间或服务帐户的 secrets 属性控制 pod 是否可以使用密钥作为环境变量或通过卷挂载。

API 访问

RBAC 用于控制是否允许身份（在您的示例中为服务帐户）通过 K8s API 访问资源。您可以通过创建 RoleBinding（命名空间）或 ClusterRoleBinding（集群范围）来控制这一点，将身份绑定到角色（命名空间）或 ClusterRole（非命名空间）到您的身份（服务帐户）。然后，当您通过设置 serviceAccountName 属性将服务帐户分配给 pod 时，在该 pod 中运行 kubectl get secret 或来自客户端库之一的等效方法将意味着您有可用的凭据来发出 API 请求。

消费秘密

但是，这与将 pod 配置为将密钥作为环境变量或卷挂载使用无关。如果 pod 规范中的容器规范引用了该秘密，则它在该容器内可用。请注意，每个容器，而不是每个 pod。您可以通过将 pod 放在不同的命名空间中来限制 pod 可以挂载的秘密，因为 pod 只能引用同一命名空间中的秘密。此外，您可以使用服务帐户的 secrets 属性来限制具有该服务帐户的 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 中了解有关 Kubernetes 机密的安全影响的更多信息。

【讨论】：

将secrets 添加到具有特定秘密名称的服务帐户（即仅读取user-service-secret 并没有阻止部署使用valueFrom.secretKeyRef 读取其他秘密（即事务服务秘密））并将它们作为环境变量注入到 pod

【解决方案2】：

这个想法是将 User-Service-Secret 机密的访问权限限制为分配给 User-Service-Pod 的 User-Service 服务帐户。所以我们可以用相关的 Kubernetes 资源（即 ServiceAccount、Role、RoleBinding）来设置这一切，但我们意识到 这可能实际上并没有强制执行，因为 Transaction-Service-Pod 可以就像在 Pod 启动时轻松读取 User-Service-Secret 密钥一样，即使分配给它的服务帐户没有获得 User-Service-Secret 的权限。

是的，这是正确的。

这是在privilege escalation via pod creation 上为 Kubernetes 记录的 - 在一个命名空间中。

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

要真正执行这种安全策略，您可能必须通过准入控制器添加额外的策略层。 OPA Gatekeeper 形式的Open Policy Agent 很可能非常适合这种策略执行。

【讨论】：