【问题标题】:Limit access to Kubernetes secret by RBAC通过 RBAC 限制对 Kubernetes 机密的访问
【发布时间】:2020-01-12 07:02:54
【问题描述】:

我已设置 Kubernetes 机密。

kubectl create secret generic mysecret --from-file=mysecret=/home/ubuntu/secret.txt

并且可以使用相同的kubectl 命令将这个秘密转换为明文:

kubectl get secret mysecret -o yaml
# and base64 decode

如何限制对这个秘密的访问?我只想要特定的 pod,并且只有我作为操作员才能访问这个秘密。

【问题讨论】:

  • 当你说限制访问时,你的意思是读还是写?
  • 是的,我想限制读写访问。

标签: kubernetes rbac


【解决方案1】:

好的,因此您需要定义一个(集群)角色,然后将其绑定到您(== 人类用户是目标实体)和/或服务帐户(== app 是目标实体),然后您use in the pod 而不是 default 一个。

各自的secretadmin 角色(或选择您喜欢的任何名称)看起来像这样(根据需要改变动词):

$ kubectl create clusterrole secretadmin \
          --verb=get --verb=list --verb=create --verb=update  \
          --resource=secret \
          --namespace=mysuperproject

定义角色后,您可以将其附加(或:绑定)到某个实体。让我们看一下服务帐户的情况(类似于人类用户,只是更简单)。所以首先我们需要创建服务帐户,这里称为thepowerfulapp,然后您将在部署/pod/whatever 中使用它:

$ kubectl -n mysuperproject create sa thepowerfulapp

现在是时候将所有内容与以下称为 canadminsecret 的绑定绑定在一起了

$ kubectl create clusterrolebinding canadminsecret \
          --role=secretadmin \
          --serviceaccount=mysuperproject:thepowerfulapp \
          --namespace=mysuperproject

【讨论】:

  • 难道不是任何能够在mysuperproject 命名空间中创建 Pod 的用户都能够将 Secret 挂载到容器中并查看它吗?
  • 是的@giorgiosironi 这是 Kubernetes 中 RBAC 的一个已知限制,IOW 如果它更细粒度,能够处理单个资源而不是命名空间/种类级别,那将是可取的。另请参阅 Vallery Lancey 和 Seth McCombs 的精彩 KubeCon 演讲,他们讨论了上述问题:youtube.com/watch?v=TZ73EBP2a9Q
  • --namespace 标志是不必要的,因为您正在创建集群角色/集群角色绑定,这些资源未绑定到命名空间,它们创建集群范围的访问控制。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-03-13
  • 1970-01-01
  • 2020-06-14
  • 2018-02-18
  • 1970-01-01
相关资源
最近更新 更多