【问题标题】:How to create users/groups restricted to namespace in Kubernetes using RBAC API?如何使用 RBAC API 在 Kubernetes 中创建受限于命名空间的用户/组?
【发布时间】:2017-05-09 15:07:30
【问题描述】:

问题

我想向 dev 组内的许多不同的开发人员(不同的主题)颁发证书,并让他们都有权在 dev 命名空间内创建和修改东西,但不能触及它之外的任何东西,绝对不能看到它外面的秘密。我怀疑我在下面第 2 步中创建的角色、角色绑定等不正确,有人可以提出更正建议吗?

尝试

  1. 部署了带有 API Server 标志的 Kubernetes,以支持“RBAC,AlwaysAllow”授权模式,设置 RBAC 超级用户,并通过 --runtime-config 启用 RBAC API。
  2. 创建了命名空间、角色和角色绑定,目的是 (a) 服务帐户和系统组件仍然可以有效地拥有“AlwaysAllow”访问权限,以及 (b) 组 dev 中的任何实体都可以访问命名空间 @ 中的任何内容987654329@ 使用this YAML file注意:此链接的内容已更改,请参阅我在问题底部处理的 YAML 文件。
  3. 将 Kubernetes 更新为仅允许“RBAC”授权模式。
  4. 生成的客户端 TLS 数据,其中证书主题标志(用于 openssl)为 -subj "/CN=example-dev@kubernetes.click/O=dev"
  5. this template之后生成了一个kubeconfig文件。

实际结果

运行时出现以下错误:kubectl -v 8 --kubeconfig=/tmp/dev-kube-config.yml create -f /tmp/busybox.yml:

I1219 16:12:37.584657   44323 loader.go:354] Config loaded from file /tmp/dev-kube-config.yml
I1219 16:12:37.585953   44323 round_trippers.go:296] GET https://api.kubernetes.click/api
I1219 16:12:37.585968   44323 round_trippers.go:303] Request Headers:
I1219 16:12:37.585983   44323 round_trippers.go:306]     Accept: application/json, */*
I1219 16:12:37.585991   44323 round_trippers.go:306]     User-Agent: kubectl/v1.5.1+82450d0 (    darwin/amd64) kubernetes/82450d0
I1219 16:12:38.148994   44323 round_trippers.go:321] Response Status: 403 Forbidden in 562     milliseconds
I1219 16:12:38.149056   44323 round_trippers.go:324] Response Headers:
I1219 16:12:38.149070   44323 round_trippers.go:327]     Content-Type: text/plain; charset=utf-    8
I1219 16:12:38.149081   44323 round_trippers.go:327]     Content-Length: 17
I1219 16:12:38.149091   44323 round_trippers.go:327]     Date: Tue, 20 Dec 2016 00:12:38 GMT
I1219 16:12:38.149190   44323 request.go:904] Response Body: Forbidden: "/api"
I1219 16:12:38.149249   44323 request.go:995] Response Body: "Forbidden: \"/api\""
I1219 16:12:38.149567   44323 request.go:1151] body was not decodable (unable to check for     Status): Object 'Kind' is missing in 'Forbidden: "/api"'
...
I1219 16:12:38.820672   44323 round_trippers.go:296] GET https://api.kubernetes.    click/swaggerapi/api/v1
I1219 16:12:38.820702   44323 round_trippers.go:303] Request Headers:
I1219 16:12:38.820717   44323 round_trippers.go:306]     User-Agent: kubectl/v1.5.1+82450d0 (    darwin/amd64) kubernetes/82450d0
I1219 16:12:38.820731   44323 round_trippers.go:306]     Accept: application/json, */*
I1219 16:12:38.902256   44323 round_trippers.go:321] Response Status: 403 Forbidden in 81     milliseconds
I1219 16:12:38.902306   44323 round_trippers.go:324] Response Headers:
I1219 16:12:38.902327   44323 round_trippers.go:327]     Content-Type: text/plain; charset=utf-    8
I1219 16:12:38.902345   44323 round_trippers.go:327]     Content-Length: 31
I1219 16:12:38.902363   44323 round_trippers.go:327]     Date: Tue, 20 Dec 2016 00:12:38 GMT
I1219 16:12:38.902456   44323 request.go:904] Response Body: Forbidden: "/swaggerapi/api/v1"
I1219 16:12:38.902512   44323 request.go:995] Response Body: "Forbidden:     \"/swaggerapi/api/v1\""
F1219 16:12:38.903025   44323 helpers.go:116] error: error validating "/tmp/busybox.yml": error validating data: the server does not allow access to the requested resource; if you choose to ignore these errors, turn validation off with --validate=false

预期结果

预计在dev 命名空间中创建busybox pod。

其他细节:

  • $ kubectl version

    Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"82450d03cb057bab0950214ef122b67c83fb11df", GitTreeState:"not a git tree", BuildDate:"2016-12-14T04:09:31Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"darwin/amd64"}
    Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"e569a27d02001e343cb68086bc06d47804f62af6", GitTreeState:"clean", BuildDate:"2016-11-12T05:16:27Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
    
  • GitHub 问题:https://github.com/kubernetes/kubernetes/issues/38997

  • 邮件列表帖子:https://groups.google.com/forum/#!topic/kubernetes-dev/6TBTu1AC2L8

编辑:基于答案 cmets

的工作解决方案

根据 Jordan 在下面的回答,我升级到了 Kubernetes v1.5.1,然后得到了以下两个 YAML 文件来构建命名空间和所有正确的 RBAC 资源,以便一切按预期工作:

system-access.yml(因为开箱即用的集群角色和集群角色绑定似乎不起作用):

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: system:node--kubelet
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node
subjects:
- kind: User
  name: kubelet
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: cluster-admin--kube-system:default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: system:node-proxier--kube-proxy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-proxier
subjects:
- kind: User
  name: kube-proxy

dev-access.yml:

kind: Namespace
apiVersion: v1
metadata:
  name: dev
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  namespace: dev
  name: dev-all
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: dev-role-dev-all-members
  namespace: dev
subjects:
  - kind: Group
    name: dev
  - kind: Group
    name: system:serviceaccounts:dev
roleRef:
  kind: Role
  name: dev-all
  apiGroup: "rbac.authorization.k8s.io"

【问题讨论】:

    标签: kubernetes client-certificates rbac kubectl


    【解决方案1】:

    首先,您需要允许访问 kubectl 用于 API 发现和验证的 URL(swagger、API 组列表和资源类型等)。

    最简单的方法是加载默认引导程序cluster rolescluster role bindings

    kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata/cluster-roles.yaml
    kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata/cluster-role-bindings.yaml
    

    这将创建一个system:discovery ClusterRole 并将所有用户(经过身份验证和未经身份验证)绑定到它,允许他们访问 swagger 和 API 组信息。

    其次,您不应在all 集群角色绑定中包含开发服务帐户。这将允许该服务帐户(以及任何有权访问包含开发服务帐户凭据的 dev 命名空间中的机密的人)集群范围的访问

    【讨论】:

    • 请注意,github.com/kubernetes/kubernetes/pull/39219 可以访问该角色中的/swaggerapi/* url
    • 谢谢乔丹。所有system:... 组来自哪里?我需要使用 Kubernetes 的某个最低版本吗?另外,我注意到这些文件中提到了一些角色,它们没有在任何绑定中使用,那么我真的需要这些角色吗?
    • 从 1.5 开始,它们会在从空 etcd 开始时自动创建。一些角色绑定到服务帐户以供控制器使用(请参阅github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/…
    • 如果我执行“git log -S'system:unauthenticated'”,我看到第一个真正的代码引用在提交 0dbcad1763,然后查看 github.com/kubernetes/kubernetes/commit/0dbcad1763似乎第一个包含它的标签是 1.5.0,这意味着这可能不适用于 1.4.6。有没有其他方法可以未经身份验证访问发现 API,这对 1.5.0 之前的人们是如何工作的?我可以尝试升级到 1.5.0,但我的集群基于尚未提供 1.5.0 支持的 kops 工具。感谢您的所有帮助。
    • 谢谢,这最终让我走了大部分路。我升级到 1.5.1,添加了一个角色来访问 dev 命名空间中的所有内容并将其绑定到 devsystem:serviceaccounts:dev 组,但是我需要添加一些额外的集群角色绑定才能让事情正常工作,即:kubelet user to system:nodekube-system::default service account to cluster-adminkube-proxy user to system:node-proxier
    猜你喜欢
    • 2016-06-10
    • 2021-12-11
    • 2020-08-28
    • 2017-11-29
    • 2021-10-24
    • 2016-10-19
    • 2021-09-12
    • 2019-03-24
    • 2019-10-08
    相关资源
    最近更新 更多