使用RBAC，通常在Kubernetes v1.8中可用

2017年10月28日，星期六

编者注：这篇文章是系列深入文章 Kubernetes 1.8的新功能。今天的帖子来自软件工程师，CoreOS和SIG-Auth联合负责人Eric Chiang。

Kubernetes 1.8代表了一个重要的里程碑基于角色的访问控制（RBAC）授权者，在此版本中已升级为GA。 RBAC是一种用于控制对Kubernetes API的访问的机制，并且自其以来测试版1.6，许多Kubernetes集群和配置策略默认情况下启用了它。

展望未来，我们希望看到RBAC成为保护Kubernetes集群的基础。本文探讨了如何使用RBAC管理用户和应用程序对Kubernetes API的访问。

授予用户访问权限

使用标准Kubernetes资源配置RBAC。用户可以通过绑定（ClusterRoleBindings和RoleBindings）绑定到一组角色（ClusterRoles和Roles）。用户没有权限开始，必须由管理员明确授予访问权限。

所有Kubernetes集群都安装了默认的ClusterRoles集，代表可以放置用户的常见存储桶。“编辑”角色使用户可以执行诸如部署Pod之类的基本操作； “视图”让用户观察非敏感资源； “ admin”允许用户管理名称空间；和“ cluster-admin”授予访问权限以管理集群。


$ kubectl get clusterroles

NAME            AGE

admin           40m

cluster-admin   40m

edit            40m

# ...


view            40m

ClusterRoleBindings向用户，组或服务帐户授予ClusterRole在整个群集中的权限。使用kubectl，我们可以通过将样本用户“ jane”绑定到“ edit” ClusterRole来在所有名称空间中执行基本操作：


$ kubectl create clusterrolebinding jane --clusterrole=edit --user=jane

$ kubectl get namespaces --as=jane

NAME          STATUS    AGE

default       Active    43m

kube-public   Active    43m

kube-system   Active    43m

$ kubectl auth can-i create deployments --namespace=dev --as=jane

yes

RoleBindings在名称空间中授予ClusterRole的权力，使管理员可以管理可在整个集群中重用的ClusterRoles的中央列表。例如，随着新资源添加到Kubernetes，默认的ClusterRoles将更新，以自动向其名称空间内的RoleBinding主题授予正确的权限。

接下来，我们让“ infra”组修改“ dev”名称空间中的资源：


$ kubectl create rolebinding infra --clusterrole=edit --group=infra --namespace=dev

rolebinding "infra" created

由于我们使用了RoleBinding，因此这些权限仅适用于RoleBinding的名称空间。在我们的例子中，“ infra”组中的用户可以在“ dev”命名空间中查看资源，但不能在“ prod”中查看资源：


$ kubectl get deployments --as=dave --as-group=infra --namespace dev

No resources found.

$ kubectl get deployments --as=dave --as-group=infra --namespace prod

Error from server (Forbidden): deployments.extensions is forbidden: User "dave" cannot list deployments.extensions in the namespace "prod".

创建自定义角色

如果默认的ClusterRoles不够用，则可以创建定义自定义权限集的新角色。由于ClusterRoles只是常规API资源，因此可以将它们表示为YAML或JSON清单，并使用kubectl进行应用。

每个ClusterRole包含一个指定“规则”的权限列表。规则是纯加性的，并允许对一组资源执行特定的HTTP动词。例如，以下ClusterRole拥有对“部署”，“ configmaps”或“秘密”执行任何操作并查看任何“ pod”的权限：


kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

 name: deployer

rules:

- apiGroups: ["apps"]

 resources: ["deployments"]

 verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]



- apiGroups: [""] # "" indicates the core API group

 resources: ["configmaps", "secrets"]

 verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]



- apiGroups: [""] # "" indicates the core API group

 resources: ["pods"]

 verbs: ["get", "list", "watch"]

动词对应于请求的HTTP动词，而资源和API组则引用所引用的资源。考虑以下Ingress资源：


apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: test-ingress

spec:

 backend:

   serviceName: testsvc

   servicePort: 80

要发布资源，用户将需要以下权限：


rules:

- apiGroups: ["extensions"] # "apiVersion" without version

 resources: ["ingresses"]  # Plural of "kind"

 verbs: ["create"]         # "POST" maps to "create"

应用程序的角色

部署需要访问Kubernetes API的容器时，最好将RBAC角色与您的应用程序清单一起发送。除了确保您的应用程序可以在启用RBAC的群集上运行之外，这还可以帮助用户审核您的应用程序将在群集上执行的操作并考虑其安全隐患。

命名空间角色通常更适合应用程序，因为传统上应用程序在单个命名空间内运行，并且命名空间的资源应与应用程序的生命周期联系在一起。但是，角色无法授予对非命名空间资源（例如节点）或跨命名空间的访问权限，因此某些应用程序可能仍需要ClusterRoles。

以下角色允许Prometheus实例监视和发现“ dev”名称空间中的服务，端点和Pod：


kind: Role

metadata:

 name: prometheus-role

 namespace: dev

rules:

- apiGroups: [""] # "" refers to the core API group

 Resources: ["services", "endpoints", "pods"]

 verbs: ["get", "list", "watch"]

在Kubernetes集群中运行的容器将接收服务帐户凭据以与Kubernetes API进行通信，并且RoleBinding可以将服务帐户作为目标。 Pod通常使用“默认”服务帐户运行，但最好使用一个唯一的服务帐户运行每个应用程序，这样RoleBindings不会无意间将权限授予其他应用程序。

To run a pod with a custom service account, create a ServiceAccount resource in the same namespace and specify the serviceAccountName field of the manifest.


apiVersion: apps/v1beta2 # Abbreviated, not a full manifest

kind: Deployment

metadata:

 name: prometheus-deployment

 namespace: dev

spec:

 replicas: 1

 template:

   spec:

     containers:

     - name: prometheus

       image: prom/prometheus:v1.8.0

       command: ["prometheus", "-config.file=/etc/prom/config.yml"]

   # Run this pod using the "prometheus-sa" service account.

   serviceAccountName: prometheus-sa

---

apiVersion: v1

kind: ServiceAccount

metadata:

 name: prometheus-sa

 namespace: dev

参与其中

RBAC的发展是通过 Auth特别兴趣小组，其中一个许多特别兴趣小组负责维护Kubernetes参与Kubernetes社区的一种好方法是加入一个符合您的兴趣，提供反馈并为路线图提供帮助的SIG。

关于作者

Eric Chiang是Kubernetes开发的软件工程师和技术主管，位于酷睿，Tectonic（适用于企业的Kubernetes平台）的创建者。 Eric共同领导Kubernetes SIG Auth，并代表CoreOS维护多个开源项目和库。

← 以前

下一个 →