【问题标题】:Granting a Kubernetes Service Account permissions for Secrets?授予 Kubernetes 服务帐户的 Secrets 权限?
【发布时间】:2019-03-15 14:31:22
【问题描述】:

我有一个服务帐户,我想授予它在特定命名空间中读取/写入/更新/删除 Secret 的权限。我不清楚服务帐户、角色、绑定等究竟如何协同工作以授予正确的权限。

我需要做什么kubectl 调用或 YAML 才能将这些权限授予服务帐户?

这是我目前拥有的服务帐户的 YAML:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2018-10-09T17:45:20Z
  name: testaccount
  namespace: test
  resourceVersion: "369702913"
  selfLink: /api/v1/namespaces/test/serviceaccounts/testaccount
  uid: f742ed5c-c1b3-11e8-8a69-0ade4132ab56
secrets:
- name: testaccount-token-brjxq

【问题讨论】:

    标签: kubernetes rbac


    【解决方案1】:

    您需要创建角色和角色绑定。

    创建角色:

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
     namespace: test
     name: role-test-account
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    

    创建角色绑定:

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
     name: role-test-account-binding
     namespace: test
    subjects:
    - kind: ServiceAccount
      name: test-account
      namespace: test
    roleRef:
     kind: Role
     name: role-test-account
     apiGroup: rbac.authorization.k8s.io
    

    你可以阅读更多关于using RBAC Authorization

    【讨论】:

      【解决方案2】:

      所以你有你的 SA testaccount。假设您的应用程序(操纵秘密的应用程序)有一个容器映像myorg/myapp:01。然后按如下方式启动它:

      $ kubectl -n test run myapp \
          --image=myorg/myapp:01 \
          --serviceaccount=testaccount
      

      但是权限呢?好吧,在应用程序启动之前或之后执行此操作并不重要,但在某个时间点,请执行以下操作:

      $ kubectl create clusterrole secretmanipulator \
          --verb=get --verb=list --verb=watch \
          --verb=create --verb=update --verb=patch --verb=delete \
          --resource=secrets 
      
      $ kubectl -n test create rolebinding allowsecretmanipulation \
          --clusterrole=secretmanipulator \
          --serviceaccount=test:testaccount 
      

      请注意,我在上面创建了一个集群角色并使用了角色绑定,然后将其附加到您的 SA。为什么?这样更可重复使用。当然,一个简单的角色也可以在这里使用,但是您需要为每个命名空间重新创建它。

      【讨论】:

      • 我接受了 YAML 解决方案的早期答案,但我很欣赏这种使用集群角色和 kubectl 调用的替代方案。
      • 是的,为了清楚起见,另一个答案虽然不正确,但并不完整,因为它没有解决在 pod 中实际使用 SA 的重要步骤;)
      • 我认为更严格和更严格的身份验证配置通常更安全。仅当您确定必须为您的服务帐户授予跨命名空间的权限时才使用集群角色 - 否则这不是一个好的 RBAC 策略。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-08-30
      • 1970-01-01
      • 2021-10-21
      • 1970-01-01
      • 2020-07-04
      • 1970-01-01
      相关资源
      最近更新 更多