k8s 权限理解

最新推荐文章于 2024-05-17 14:10:47 发布

weixin_34106122

最新推荐文章于 2024-05-17 14:10:47 发布

阅读量1k

点赞数

文章标签：运维数据库

原文链接：http://blog.51cto.com/running/2323375

版权

kubernetes 权限管理

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

认证(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
}

kube-apiserver配置文件里添加--anonymous-auth=false才会出现如下登录页面

k8s 权限理解

用户名和密码是在kube-apiserver的--basic-auth-file=/etc/kubernetes/base_file.csv文件里配置的,格式如上面所示
当输入用户名和密码后发现还是打不开页面,提示以下页面

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}

那是因为base_file.csv中的admin没有授权,执行下面命令进行授权

kubectl create clusterrolebinding login-dashboard-admin --clusterrole=cluster-admin --user=admin

然后再打开页面就会出现下面的页面
k8s 权限理解

此处进行令牌验证,如何获取令牌,如下

#root@<cc_172.16.0.2|~/cfssl>:# kubectl get secret -n kube-system 
NAME                               TYPE                                  DATA   AGE
admin-token-wbjtp                  kubernetes.io/service-account-token   3      2d18h
coredns-token-lxsg5                kubernetes.io/service-account-token   3      4d19h
default-token-b4jq9                kubernetes.io/service-account-token   3      8d
kubernetes-dashboard-certs         Opaque                                0      2d18h
kubernetes-dashboard-key-holder    Opaque                                2      2d18h
kubernetes-dashboard-token-tbkh5   kubernetes.io/service-account-token   3      2d18h
#root@<cc_172.16.0.2|~/cfssl>:# kubectl describe secret -n kube-system kubernetes-dashboard-token-tbkh5
Name:         kubernetes-dashboard-token-tbkh5
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: kubernetes-dashboard
              kubernetes.io/service-account.uid: 34fc9238-f181-11e8-94ca-5254f7a51592

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1359 bytes
namespace:  11 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZC10b2tlbi10YmtoNSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjM0ZmM5MjM4LWYxODEtMTFlOC05NGNhLTUyNTRmN2E1MTU5MiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTprdWJlcm5ldGVzLWRhc2hib2FyZCJ9.39CU5S9vc3oXVvblSYdAo4_GStyBroXX3PETPQ9xw1kOmIBcM-0qFRIV5uFrFKyWHSt0hSm7QMOCPJvjlTkB2ZmwhSFApwHosKpBmhKPinBGDXK1lRZJq_kwq6pQU_Ys8mhZ_yM74VyfKjCQ6YvKvuiv3iC_hncVG1aAs3VXbrM6o271hhoovOH4pr4YHrNNFMAzsxbbfNa5zfSe3oOtuP1CQfSb464Wnsn5KBI5p0nuvClCqUco_GpgfadW6zSLDiRcuaYsy25UMQwlLNyLx-SdenpLv5aGhw9Ml1ts5q3fxe58-dw4ALUTFJTFF4y3s-RQR0sqy9l7kdcxxJGnoA

把最下面token那一段复制出来拷贝到浏览器中进行令牌验证,然后点击确认就可以登录了
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 定义了 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 这个角色

转载于:https://blog.51cto.com/running/2323375

weixin_34106122

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
k8s 权限理解

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

扫一扫