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