在Kubernetes v1.8中使用RBAC

Kubernetes 1.8一个重要里程碑是推出了基于角色的访问控制(RBAC)授权，在这个版本中被提升为GA。RBAC是一种控制访问Kubernetes API的机制，因为在1.6中推出beta版，许多Kubernetes集群和配置策略在默认情况下都启用了它。

展望未来，我们预计RBAC将成为保护Kubernetes集群的基础。本文介绍使用RBAC管理用户和应用程序访问Kubernetes API。

向用户授予访问

RBAC使用标准Kubernetes资源配置，用户可以通过绑定(ClusterRoleBindings和RoleBindings)到一组角色(集群角色和角色)。用户启动时没有权限，必须由管理员明确授予访问权限。

所有Kubernetes集群都安装了一组默认的集群角色，表示可以放置用户的公共bucket。“edit”角色允许用户执行像部署pod这样的基本操作，“view”让用户观察非敏感资源，“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的权力，允许管理员管理集群中重用的集群角色的中心列表。例如，当新资源被添加到Kubernetes时，默认的clusterrole会被更新，以自动授予其命名空间内的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”或“secrets”执行任何操作的权限，并查看任何“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”]

verbs对应于HTTP请求，而resources和apiGroups则引用被引用的资源。考虑以下的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”名称空间中的服务、endpoint和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通常使用“default”服务帐户运行，但良好的做法是使用一个独特的服务帐户运行每个应用程序，这样RoleBindings就不会无意中授予其他应用程序的权限。要使用自定义服务帐户运行一个pod，在同一个名称空间中创建一个ServiceAccount资源，并指定manifest的“serviceAccountName”字段。

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

本文出自http://www.sohu.com/a/205750642_610730