kubernetes v1.8.4 RBAC DENY 解决办法
二进制方式部署好k8s集群v1.8.4后,开启rbac认证后,所有组件均无法与apiserver正常通信,apiserver日志报错,大量的组件都是RBAC DENY状态。 按照k8s官方文档(https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions),存在如下的clus
二进制方式部署好k8s集群v1.8.4后,开启rbac认证后,所有组件均无法与apiserver正常通信,apiserver日志报错,大量的组件都是RBAC DENY状态。
按照k8s官方文档(https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions),存在如下的clusterrolebing。
参照此,设置各个组件的kubeconfig文件时,均按此设置了用户名。
按此操作后,发现还是存在RBAC DENY问题。后来对比官方文档部署过程的CA设置,发现问题在CA认证证书制作上面。之前笔者是用的easy-rsa3制作的相关证书,指定的信息比较简单,而在集群开启ca认证时,apiserver获取其他组件的连接请求信息时,用户名和属组信息,不是从kubeconfig文件获取的,而是通过ca里面的信息,所以制作证书的过程中就得把相关信息写到证书里面去。后改为使用cfssl来制作证书。
1 生成ca证书和私钥
2 生成apiserver证书
"CN":Common Name,kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name);
"O":Organization,kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group);kubernets X509证书验证模式,会将该group通过cluster-admin这个clusterrolebinding 绑定到cluster-admin这个cluster-role,继而获得所有的kube-api访问权限。
3 创建管理员证书(cluster-admin的集群角色)
后面证书kube-controller-manager,kube-schduler,kube-proxy制作类似,修改xxx-csr.json的CN字段即可.
参考:
https://www.kubernetes.org.cn/1861.html
https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions
更多推荐
所有评论(0)