注:通过RBAC对集群进行加固
关于RBAC
RBAC-role based access control 基于角色的访问控制
注:ABAC(基于属性的访问控制),ABAC木有接触过…
1. Introduction to RBAC RBAC介绍
"Role-based access control (RBAC) is a method of regulating accessto computer or network resources based on the roles of individualusers within your organization."
基于角色的访问控制(RBAC)是一种根据个人用户在组织中的角色来管理对计算机或网络资源的访问的方法。
RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策,允许管理员通过 Kubernetes API 动态配置策略,要启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,1.6 版本以上的都默认开启了RBAC,可以通过查看 Master 节点上 apiserver 的静态Pod定义文件:
RBAC 流程定义三大组件: subject Role rolebinding 主体 授权规则 准入控制
1. 访问Kubernetes资源时,限制对Kubernetes资源的访问基于用户或ServiceAccount
2. 使用角色和绑定
3. 指定允许的内容,其他所有内容都将被拒绝.可以设置白名单
4. POLP-Priciple of Least Privilege最小特权原则
** 仅访问合法目的所需的数据或信息**
2. RBAC的资源分类 命名空间级别and 非命名空间级别(集群级别)
常用查询命令
查询在namespace中的资源对象 执行命令:kubectl api-resources --namespaced=true 查询不在namespace中的资源对象 执行命令:kubectl api-resources --namespaced=false 查询资源对象与namespace的关系 执行命令:kubectl api-resources
3. 关于role rolebinding clusterrole clusterrolebinding
其实从上面第五节的:kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false两个图中就能看出来:
1. role rolebinding是限制于命名空间的。
2. clusterrole和clusterrolebinding是适用于全部命名空间的没有命名空间的限制,适用于整个集群。
3. 关于role
相同的角色名称在不同的命名空间中表现不同,如下面的例子blue与red命名空间中都有名为secret-manager的role.
用户x可以是多个命名空间中的秘钥管理员,但是权限可以是不同的。
4. 关于clusterrole
clusterrole是没有命名空间限制的 权限针对与cluster 集群。
clusterrole在集群中所有的命名空间的都是相同的
用户x可以是多个命名空间中的秘密管理员,每个用户的权限都相同
3. RBAC实现方式
1. Role->RoleBinding 用户具有单个命名空间的权限
2. ClusterRole->ClusterRoleBinding 用户具有全部命名空间的相同权限
3. ClusterRole->RoleBinding 用户在多个命名空间中具有相同的权限(会使clusterrole降级)
RoleBinding对象也可以引用一个ClusterRole对象用于在RoleBinding所在的命名空间内授予用户对所引用的ClusterRole中 定义的命名空间资源的访问权限。
这一点允许管理员在整个集群范围内首先定义一组通用的角色,然后再在不同的命名空间中复用这些角色.
csdn小凡这里写的有各种的例子https://zzq23.blog.csdn.net/article/details/109680359。
4. role和 Clusterrolebinding是无法绑定的
5. 权限是可以累加的
更为详细的还是看官方文档:https://kubernetes.io/docs/reference/access-authn-authz/rbac/
4.RBAC各种场景
1. Role-> RoBinding
- 创建 red blue两个命名空间
- 赋予用户jane在red空间内可以get secrets的权限
- 赋予用户jane在blue空间可以get list secrets的权限
kubectl create ns red kubectl create ns blue kubectl -n red create role secret-manager --verb=get --resource=secrets -oyaml kubectl -n red create rolebinding secret-manager --role=secret-manager --user=jane kubectl -n blue create role secret-manager --verb=get --verb=list --resource=secrets kubectl -n blue create rolebinding secret-manager --role=secret-manager --user=jane # check permissions
- 使用auth can-i进行测试
kubectl red auth can-i -h 获取帮助
root@cks-master:~/rbac# kubectl -n red auth can-i get secrets --as jane yes root@cks-master:~/rbac# kubectl -n red auth can-i get secrets --as tom no root@cks-master:~/rbac# kubectl -n red auth can-i delete secrets --as tom no root@cks-master:~/rbac# kubectl -n red auth can-i list secrets --as tom no root@cks-master:~/rbac# kubectl -n blue auth can-i list secrets --as tom no root@cks-master:~/rbac# kubectl -n blue auth can-i list secrets --as jane yes root@cks-master:~/rbac# kubectl -n blue auth can-i get secrets --as jane yes
2. Clusterrole-> (Cluster)RoleBding
- 创建 名为deploy-deleter的 clusterrole 可以删除deployments
- 赋予用户jane可以在所有空间内删除deployments的权限
- 赋予用户jim只能在red空间内删除deployments的权限
- auth can-i测试
root@cks-master:~/rbac# kubectl create clusterrole deploy-deleter --verb=delete --resource=deployments dclusterrole.rbac.authorization.k8s.io/deploy-deleter created root@cks-master:~/rbac# kubectl create clusterrolebinding deploy-deleter --user jane --clusterrole=deploy-deleter clusterrolebinding.rbac.authorization.k8s.io/deploy-deleter created root@cks-master:~/rbac# kubectl create rolebinding deploy-deleter --user=jim --clusterrole=deploy-deleter -n red rolebinding.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jane yes root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jane -A yes root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jane -n default yes root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jane -n red yes root@cks-master:~/rbac# kubectl auth can-i delete pods --as jane -n red no root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jim -n default no root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jim -A no root@cks-master:~/rbac# kubectl auth can-i delete deployments --as jim -n red yes
3. Accounts and Users
1. serviceaccount and nornal user
1. kubernetes api管理的serviceaccount资源
2. 普通用户:不是kubernetes 管理的独立于集群服务的管理用户,由谷歌或者亚马逊这样的云平台管理的用户
- 分配私钥的管理员
- 用户商店(例如Keystone或Google帐户)
- 包含用户名和密码列表的文件
详见:https://kubernetes.io/docs/reference/access-authn-authz/authentication/
2. 关于用户和证书(这是normal user体系)
- 独立于k8s体系
- 使用证书与秘钥与k8s集群交互
关于证书与集群的交互过程就先不求甚解,后期补上。
1. CSR-CertificateSigningRequest—证书签名请求
关于证书签名请求的过程,还是不求甚解了。证书的有时间单独拿出来研究了。
2. Users and Certifiates-leak + Invalidation 用户与证书的 泄漏+无效
无法使证书无效
如果证书泄漏
- 删除通过RBAC的所有访问权限
- 证书过期之前不能使用用户名
- 创建新的CA并重新颁发所有证书
5. Users and Certifcates
1. Create Key and Create CSR
openssl genrsa -out jane.key 2048 openssl req -new -key jane.key -out jane.csr # only set Common Name = jane
2. 使用kubernetes API签署证书签名请求
http://blog.itpub.net/69955379/viewspace-2681334/ vim删除单行多行
root@cks-master:~/work/key# kubectl create -f csr.yaml certificatesigningrequest.certificates.k8s.io/jane created root@cks-master:~/work/key# cat csr.yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: jane spec: groups: - system:authenticated request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ21UQ0NBWUVDQVFBd1ZERUxNQWtHQTFVRUJoTUNRVlV4RXpBUkJnTlZCQWdNQ2xOdmJXVXRVM1JoZEdVeApJVEFmQmdOVkJBb01HRWx1ZEdWeWJtVjBJRmRwWkdkcGRITWdVSFI1SUV4MFpERU5NQXNHQTFVRUF3d0VhbUZ1ClpUQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU1BanRQakxIa2JlSlEySzFsM2oKSXJ0dWkwSDY5ZUh6bzQ4c0liMDZsamk2ZlBMS1lDQ2hjbG84ajF1YUlyNHhZUHZEZzBCbnhVNExaVDZFVjErZApDT01teFJOa3ZZaGRIZE9XMm5RSll1RGN3K2M5WXo3NjVLMllnWFE5NFhGaFkvYW9LdWRVM1pzMDhQdkwrenhXClNEbGxBOWorWDJZNExESnV6emNDZDlkRTNQcFlQUXFSQUZFdzVPd3krbHlhRWhKdkZxV29IeDdCSFNWdzcxZW8KTTJZaFhnQ0Q2eDNXY0lVQ0Z6Q1FBWmtkQ1g0SCs5Sk1XVE1xa0hjQWN2Mk8zREpDK25lSGg5S1pKbnJ1RzNvTwpIc1BvcFZsZzBiZ1V3TWFvSlg2K1dpWW5EOWszbVRIenlhTjVjQ1l5YkZNa0lkZmZXTE5kWTJTU2hMQThMRzFUCk16c0NBd0VBQWFBQU1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ21UbDBXejNQOWhpY2xJcnhPTTB3LzFXMFoKQWtRYlYvNjU5MU8rOUNUNVJFYnFFbUxhY2RwazQ3NGpKR1ZvdjREbVJvdVlPbXNPWXFtem5acWxhL0MwMGMwRQpRUkxWWjJpNGlLWTNpSWpjSWdoVWQzWUZHbk84NEhNU3NUNEIzaDMxZWtTNFF1YVRDSnFGYU84eHNDeTdpMElnClRYcnlJNCtaOEhoeElVcGNZZ0xaRDR5K3BNYUxZSnVxSmtuUU1idy9QbU5ra0trOUEwWlp6Ym9aRVNUelhpeWEKcVB3azlxZXladzJSOGo0cVI3aXlMQ0VZL05DdkFBQXNzN28zYkVSV1ltbTQveHRPT0NFN2lKRk15MWNmczVJbwpPNnptNndaYUl6dDVUNmh5TUp2RWdCV3BMd3R5Nmt1TFlNRzhNR0lnakJJY1p4ckh2Vm9xWXJ2VXk3ejMKLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg== signerName: kubernetes.io/kube-apiserver-client usages: - client auth root@cks-master:~/work/key# kubectl get csr NAME AGE SIGNERNAME REQUESTOR CONDITION jane 21s kubernetes.io/kube-apiserver-client kubernetes-admin Pending root@cks-master:~/work/key# kubectl certificate -h Modify certificate resources. Available Commands: approve Approve a certificate signing request deny Deny a certificate signing request Usage: kubectl certificate SUBCOMMAND [options] Use "kubectl <command> --help" for more information about a given command. Use "kubectl options" for a list of global command-line options (applies to all commands). root@cks-master:~/work/key# kubectl certificate approve jane certificatesigningrequest.certificates.k8s.io/jane approved root@cks-master:~/work/key# kubectl get csr NAME AGE SIGNERNAME REQUESTOR CONDITION jane 119s kubernetes.io/kube-apiserver-client kubernetes-admin Approved,Issued
kubectl get csr jane -o yaml
3. Cert+Key签署CSR连接K8sAPI
kubectl config set-credentials jane --client-key=jane.key --client-certificate=jane.crt kubectl config set-credentials jane --client-key=jane.key --client-certificate=jane.crt --embed-certs
设置上下文参数,包含集群名称和访问集群的用户名字
kubectl config set-context jane --cluster=kubernetes --user=jane
切换jane为默认用户 auth can-i测试
root@cks-master:~/work/key# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE jane kubernetes jane * kubernetes-admin@kubernetes kubernetes kubernetes-admin root@cks-master:~/work/key# kubectl config u unset use-context root@cks-master:~/work/key# kubectl config use-context jane Switched to context "jane". root@cks-master:~/work/key# kubectl get ns Error from server (Forbidden): namespaces is forbidden: User "jane" cannot list resource "namespaces" in API group "" at the cluster scope root@cks-master:~/work/key# kubectl get secrets -n blue NAME TYPE DATA AGE default-token-hb47b kubernetes.io/service-account-token 3 34h root@cks-master:~/work/key# kubectl delete secret default-token-hb47b -n blue Error from server (Forbidden): secrets "default-token-hb47b" is forbidden: User "jane" cannot delete resource "secrets" in API group "" in the namespace "blue" root@cks-master:~/work/key# kubectl auth can-i delete deployment -A yes root@cks-master:~/work/key# kubectl auth can-i delete pods -A no