使用 kube2iam 时如何避免角色升级答案

【问题标题】：How to avoid role escalation when using kube2iam使用 kube2iam 时如何避免角色升级
【发布时间】：2017-06-09 19:02:05
【问题描述】：

当尝试在 AWS 上设置 kube 集群时，我们希望能够将 IAM 角色与某些容器相关联，因此考虑使用允许您执行此操作的众多工具之一，例如 kube2iam。通过基于部署中的注释代理承担角色，所有工具似乎都以相同的方式工作。这难道不是允许一个容器通过更改注释来承担任何其他容器的角色，从而实现角色升级吗？

来自 kube2iam 自述文件：

问题在于，在基于多租户容器的世界中，多个容器将共享底层节点。鉴于容器将共享相同的底层节点，通过 IAM 角色提供对 AWS 资源的访问意味着需要创建一个 IAM 角色，该角色是所有 IAM 角色的联合。从安全角度来看，这是不可接受的。

据我了解，如果引入恶意 pod，所描述的问题仍然存在。人们目前如何解决这个问题/这是我应该担心的事情吗？

【问题讨论】：

如果你不给 Pod 访问 Kubernetes API 的权限，那么他们怎么能改变他们的注解呢？
@PixelElephant 你是对的，但我更关心控制部署管道的过程，并且违反了最小权限原则。例如，将 2 个服务部署到同一个集群“hello world”和“个人信息服务”作为有权将“hello world”服务部署到集群的人，我应该无法承担“个人信息服务”的角色但我可以通过更改注释来实现。
你说的不再是恶意 pod，而是恶意的人。 kube2iam 帮不了你。您可以以某种方式在您的部署管道中构建一个系统来检查部署是否存在iam.amazonaws.com/role 并对其进行验证。但我不知道你想要什么开箱即用的解决方案。

标签： amazon-web-services kubernetes amazon-iam

【解决方案1】：

您可以通过命名空间限制使用的角色。

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    iam.amazonaws.com/allowed-roles: |
      ["role-arn"]
  name: default

启用 k8s RBAC 后，您的部署不应具有更新命名空间注释的权限。

【讨论】：