Kubernetes 权限管理

kubernetes 主要经过 APIServer 对外提供服务，对于这样的系统集群来讲，请求访问的安全性是很是重要的考虑因素。若是不对请求加以限制，那么会致使请求被滥用，甚至被黑客攻击。

kubernetes 对于访问 API 来讲提供了两个步骤的安全措施：认证和受权。认证解决用户是谁的问题，受权解决用户能作什么的问题。经过合理的权限管理，可以保证系统的安全可靠。

下图是 API 访问要通过的三个步骤，前面两个是认证和受权，第三个是 Admission Control，它也能在必定程度上提升安全性，不过更可能是资源管理方面的做用。

NOTE： 只有经过 HTTPS 访问的时候才会经过认证和受权，HTTP 不须要。

k8s-aaa.png

Authentication (认证)

All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users.

当您（真人用户）访问集群（例如使用kubectl命令）时，apiserver 会将您认证为一个特定的 User Account（目前一般是admin，除非您的系统管理员自定义了集群配置）。Pod 容器中的进程也能够与 apiserver 联系。 当它们在联系 apiserver 的时候，它们会被认证为一个特定的 Service Account（例如default）。

normal users

normal users 由外部系统管理，并不禁 kubernetes 管理，kubernetesq API中也没有关于 normal users 的定义，因此不能经过 kubernetes API 建立和管理。

service accounts

Service Account 用来访问 kubernetes API，经过 kubernetes API 建立和管理，每一个 account 只能在一个 namespace 上生效，存储在 kubernetes API 中的 Secrets 资源。kubernetes 会默认建立，而且会自动挂载到 Pod 中的 /run/secrets/kubernetes.io/serviceaccount 目录下。

Authorization （受权）

RBAC（Role-Based Access Control）

要启用RBAC，请使用--authorization-mode=RBAC启动API Server。

RBAC 是官方才 1.6 版本以后推荐使用的受权方式，由于它比较灵活，并且可以很好地实现资源隔离效果。

这种方法引入了一个重要的概念：Role，翻译成角色。全部的权限都是围绕角色进行的，也就是说角色自己会包含一系列的权限规则，代表某个角色能作哪些事情。好比管理员能够操做全部的资源，某个 namespace 的用户只能修改该 namespace的内容，或者有些角色只容许读取资源。角色和 pods、services 这些资源同样，能够经过 API 建立和删除，所以用户能够很是灵活地根据需求建立角色。

Role与ClusterRole

在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否认”的规则）。 角色能够由命名空间（namespace）内的Role对象定义，而整个Kubernetes集群范围内有效的角色则经过ClusterRole对象实现。

一个Role对象只能用于授予对某一单一命名空间中资源的访问权限。 如下示例描述了”default”命名空间中的一个Role对象的定义，用于授予对pod的读访问权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # 空字符串""代表使用core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole对象能够授予与Role对象相同的权限，但因为它们属于集群范围对象， 也可使用它们授予对如下几种资源的访问权限：

• 集群范围资源（例如节点，即node）
• 非资源类型endpoint（例如”/healthz”）
• 跨全部命名空间的命名空间范围资源（例如pod，须要运行命令kubectl get pods --all-namespaces来查询集群中全部的pod）

下面示例中的ClusterRole定义可用于授予用户对某一特定命名空间，或者全部命名空间中的secret（取决于其绑定方式）的读访问权限：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # 鉴于ClusterRole是集群范围对象，因此这里不须要定义"namespace"字段
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding与ClusterRoleBinding

角色绑定将一个角色中定义的各类权限授予一个或者一组用户。 角色绑定包含了一组相关主体（即subject, 包括用户——User、用户组——Group、或者服务帐户——Service Account）以及对被授予角色的引用。 在命名空间中能够经过RoleBinding对象授予权限，而集群范围的权限授予则经过ClusterRoleBinding对象完成。

RoleBinding能够引用在同一命名空间内定义的Role对象。 下面示例中定义的RoleBinding对象在”default”命名空间中将”pod-reader”角色授予用户”jane”。 这一受权将容许用户”jane”从”default”命名空间中读取pod。

# 如下角色绑定定义将容许用户"jane"从"default"命名空间中读取pod。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

参考

• kubernetes 权限管理
• Securing a Cluster

 

做者：猴子精h 连接：https://www.jianshu.com/p/e14203450bc3 來源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。