k8s 权限理解
k8s 权限理解kubernetes 权限管理kubernetes 主要通过 APIServer 对外提供服务,请求访问的安全性是非常重要的考虑因素kubernetes 对于访问 API 来说提供了两个步骤的安全措施:认证和授权认证:解决用户是谁授权:解决用户能做什么注:k8s在访问时,只有通过 HTTPS 访问的时候才会通过认证和授权,HTTP 不需要K8s的认证包含以下3种方式。这3种方式可以
k8s 权限理解
kubernetes 权限管理
kubernetes 主要通过 APIServer 对外提供服务,请求访问的安全性是非常重要的考虑因素
kubernetes 对于访问 API 来说提供了两个步骤的安全措施:认证和授权
认证:解决用户是谁
授权:解决用户能做什么
注:k8s在访问时,只有通过 HTTPS 访问的时候才会通过认证和授权,HTTP 不需要
K8s的认证包含以下3种方式。这3种方式可以同时存在,认证时只按一种即可。
-
证书认证
设置apiserver的启动参数:--client_ca_file=SOMEFILE。
-
Token认证
设置apiserver的启动参数:--token_auth_file=SOMEFILE。
-
基本信息认证
设置apiserver的启动参数:--basic_auth_file=SOMEFILE。
K8s的用户分两种,一种是普通用户,一种是ServiceAccount(服务账户)。
1.1普通用户是假定被外部或独立服务管理的。管理员分配私钥。平时常用的kubectl命令都是普通用户执行的。
1.2ServiceAccount(服务帐户)是由Kubernetes API管理的用户。它们绑定到特定的命名空间,并由API服务器自动创建或通过API调用手动创建。服务帐户与存储为Secrets的一组证书相关联,这些凭据被挂载到pod中,以便集群进程与Kubernetes API通信。(登录dashboard时我们使用的就是ServiceAccount)
普通用户并不是通过k8s来创建和维护,是通过创建证书和切换上下文环境的方式来创建和切换用户。
创建用户证书
创建devuser-csr.json文件:
k8s的用户名就是从CN上获取的。组是从O上获取的。这个用户或者组用于后面的角色绑定使用
认证(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”
搭建好dashboard后kube-apiserver配置文件中没有加入(–anonymous-auth=false)浏览器访问下面链接是不会出现下图的登录页面
https://masterip或者mastervip:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
访问链接可以通过执行下面命令查看,172.16.0.100是keepalived为kube-apiserver负载均衡vip
#root@<cc_172.16.0.2|~/cfssl>:#kubectl cluster-info
Kubernetes master is running at https://172.16.0.100:6443
CoreDNS is running at https://172.16.0.100:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://172.16.0.100:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
浏览器会报如下错误
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "services \"https:kubernetes-dashboard:\" is forbidden: User \"system:anonymous\" cannot get services/proxy in the namespace \"kube-system\"",
"reason": "Forbidden",
"details": {
"name": "https:kubernetes-dashboard:",
"kind": "services"
},
"code": 403
}
k8s 权限理解
静态 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
RBAC定义了 Role 和 ClusterRole,分别对应单个 namespace 的权限和整个集群的权限,来对两者进行区分
权限就是对某个资源可以执行什么样的操作,操作可以是
- get、
- list、
- watch、
- create、
- update、
- patch
- delete,
- 资源对应 kubernetes API 管理的资源
比如
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S9AFZG2a-1603355432238)(/Users/zhaobei/Library/Application Support/typora-user-images/image-20200716173643687.png)]
上面定义了两个权限,分别是读取 pods 和读写 jobs 资源
有了权限之后,最终还是要对应到用户上面,用户和角色之间可以进行绑定,绑定后的用户就能拥有对应角色的所有权限。比如我们可以添加一个管理员角色,然后把公司的某几个人设置(绑定)成管理员。一个用户可以和多个角色进行绑定,同时应用这些角色的权限。
和 Role 一样,RBAC 也有两种资源:RoleBinding 和 ClusterRoleBinding,分别对应单个 namespace 和整个集群范围
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zbL1AtWD-1603355432239)(/Users/zhaobei/Library/Application Support/typora-user-images/image-20200716173731033.png)]
把用户 jane 绑定到 pod-reader 这个角色
更多推荐
所有评论(0)