k8s 权限理解

标签：配置   引号   rbac   webhook   k8s   访问控制   环境   ane   验证   

1. kubernetes 主要通过 APIServer 对外提供服务，请求访问的安全性是非常重要的考虑因素
2. kubernetes 对于访问 API 来说提供了两个步骤的安全措施：认证和授权
   认证:解决用户是谁
   授权:解决用户能做什么
   注:k8s在访问时,只有通过 HTTPS 访问的时候才会通过认证和授权，HTTP 不需要
3. 认证（Authentication）

   客户端证书认证
   在kube-apiserver配置文件中添加 --client-ca-file=/srv/kubernetes/ca.crt，也就是client证书校验机制。apiserver会用/etc/kubernetes/pki/ca.crt对client端发过来的client.crt进行验证

静态密码文件认证,在kube-apiserver配置文件是指定明文的文件存放用户名,密码,id号
--basic-auth-file=/etc/kubernetes/base_file.csv
--anonymous-auth=false (匿名认证要关闭,不然访问url不会提示输入用户名和密码，会提示system:anonymous)
静态密码文件是 CSV 格式,每行对应一个用户的信息，前面三列密码、用户名、用户 ID 是必须的，第四列是可选的组名（如果有多个组，必须用双引号）password,user,uid,"group1,group2,group3"

静态 Token 文件认证
事先在一个文件中写上用户的认证信息（用户名、用户 id、token、用户所在的组名）,apiserver 启动通过参数
--token-auth-file=SOMEFILE
指定这个文件，apiserver 把这些信息加载起来。token 文件是 CSV 格式的文件，每行代表一个用户的信息，至少包含 token、用户名和用户 ID 三列，最后一列组名列表是可选的（如果有多个组必须用双引号括起来），比如：token,user,uid,"group1,group2,group3"

Service Account Tokens 认证
Service Account 是面向 namespace 的，每个 namespace 创建的时候，kubernetes 会自动在这个 namespace 下面创建一个默认的 Service Account；并且这个 Service Account 只能访问该 namespace 的资源。Service Account 和 pod、service、deployment 一样是 kubernetes 集群中的一种资源，用户也可以创建自己的 serviceaccount。

二、授权（Authorization）
授权发生在认证之后，通过认证的请求就能知道 username，而授权判断这个用户是否有权限对访问的资源执行特定的动作
控制不同用户能操作哪些内容就是授权要做的事情。
在启动 apiserver 可以通过 --authorization_mode 参数来指定授权模式，目前支持的模式有：

AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node

AlwaysDeny：阻止所有的请求访问，只用于测试环境
AlwaysAllow：允许所有的请求访问，注意这个模式下没有对请求进行限制，只有你能确保没有恶意请求的时候使用
ABAC：基于属性的访问控制
RBAC：基于角色的访问控制，这是 1.6 版本之后开始推荐的授权方式
WebHook：
kubernetes apiserver 根据事先定义的授权策略 来决定用户是否有权限访问。每个请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回 403 Unauthorized 错误。

kubernetes 把请求分成了两种：资源请求和非资源请求。资源请求是对 kubernetes 封装的资源实体的请求，比如 pods、nodes、services 等；非资源请求相反，是对诸如 /api、/metrics、healthz 等和资源无关的请求。它们两者的授权也有区别

RBAC 定义了 Role 和 ClusterRole，分别对应单个 namespace 的权限和整个集群的权限，来对两者进行区分
权限就是对某个资源可以执行什么样的操作，操作可以是 get、list、watch、create、update、patch 和 delete，资源对应 kubernetes API 管理的资源
比如

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

上面定义了两个权限，分别是读取 pods 和读写 jobs 资源

有了权限之后，最终还是要对应到用户上面，用户和角色之间可以进行绑定，绑定后的用户就能拥有对应角色的所有权限。比如我们可以添加一个管理员角色，然后把公司的某几个人设置（绑定）成管理员。一个用户可以和多个角色进行绑定，同时应用这些角色的权限。

和 Role 一样，RBAC 也有两种资源：RoleBinding 和 ClusterRoleBinding，分别对应单个 namespace 和整个集群范围

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

把用户 jane 绑定到 pod-reader 这个角色

k8s 权限理解

标签：配置   引号   rbac   webhook   k8s   访问控制   环境   ane   验证   

原文地址：http://blog.51cto.com/running/2323375