Kubernetes中的RBAC

时间:2022-06-01 19:49:31

Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。需要在kube-apiserver设置–authorization-mode=RBAC参数,启用RABC模式,下面的操作版本为v1.10.1;

  当应用没有指定serviceAccountName,它将使用default服务帐户。

  在RABC API中,通过如下的步骤进行授权:

  1)定义角色:定义角色时会指定此角色对于资源的访问控制的规则;

  2)定义主体:用户、组和服务帐户

  3)绑定角色:将主体与角色进行绑定,对主体进行访问授权。

Kubernetes中的RBAC

                    RBAC API中的对象关系图

  Kubernetes中角色包含代表权限集合的规则,权限只有被授予,没有被拒绝的设置。

  在Kubernetes中有两类角色:普通角色和集群角色。

可以通过Role定义在一个命名空间中的角色,或是使用ClusterRole定义集群范围的角色。

普通角色只能被授予访问单一命令空间中的资源。

集群角色(ClusterRole)能够被授予资源权限有:集群范围资源(Node、NameSpace)、非资源端点(/healthz)、集群所有命名空间资源(跨名称空间);

角色绑定和集群角色绑定

  角色绑定用于将角色与一个主体进行绑定,从而实现将对主体授权的目的,主体分为用户、组和服务帐户。

角色绑定分为:普通角色绑定和集群角色绑定

角色绑定中不同主体定义有:

名称为 demo 用户:

 subjects:
- kind:User
name:"demo"
apiGroup:rbac.authorization.k8s.io

名称为 demo 组:

 subjects:
- kind:Group
name:"demo-group"
apiGroup:rbac.authorization.k8s.io

kube-system命名空间中,名称为default的服务帐户

 subjects:
- kind:ServiceAccount
name:default
namespace:kube-system

so命名空间中,所有的服务帐户:

 subjects:
- kind:Group
name:system:serviceaccounts:so
apiGroup:rbac.authorization.k8s.io

所有的服务帐户:

 subjects:
- kind:Group
name:system:serviceaccounts
apiGroup:rbac.authorization.k8s.io

所有用户:

 subjects:
- kind:Group
name:system:authenticated #授权用户
apiGroup:rbac.authorization.k8s.io
- kind:Group
name:system:unauthenticated #未授权用户
apiGroup:rbac.authorization.k8s.io

授予cluster-admin集群角色给admin用户:

 kubectl create clusterrolebinding admin-cluster-admin-binding --clusterrole=cluster-admin --user=admin

授予cluster-admin集群角色给so名称空间中的app服务帐户:

 kubectl create clusterrolebinding app-admin-binding --clusterrole=cluster-admin --serviceaccount=so:app

  RBAC实例demo下面创建solinx-service-account.yml文件包含以下内容:

 # 服务账号
apiVersion: v1
kind: ServiceAccount
metadata:
name: solinx
# 角色
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: solinx
rules: #规则
- apiGroups: [""] # 所有核心api
resources: ["pods"] # 资源
verbs: ["create","delete","get","list","patch","update","watch"] #操作
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["create","delete","get","list","patch","update","watch"]
# 角色绑定
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: solinx
roleRef: # 上面定义的角色
apiGroup: rbac.authorization.k8s.io
kind: Role
name: solinx
subjects: # 上面定义的服务账户
- kind: ServiceAccount
name: solinx
namespace: default

  上面定义了一个服务账户solinx、普通角色solinx,并将该服务账户与角色进行绑定,该角色定义了对了pod的增删查改等操作,所以该服务账户也具备了该权限;

  这里使用solinx服务账户对资源进行操作:

 kubectl get po --as system:serviceaccount:default:solinx

Kubernetes中的RBAC

由于只授予了pod的操作权限,当访问service资源时被拒绝:

 kubectl get svc --as system:serviceaccount:default:solinx

 Error from server (Forbidden): services is forbidden: User "system:serviceaccount:default:solinx" cannot list services in the namespace "default"

Kubernetes中的RBAC

该角色为普通角色Role,当访问集群资源NameSpace时同样被拒绝:

 kubectl get ns --as system:serviceaccount:default:solinx

 Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount:default:solinx" cannot list namespaces at the cluster scope

Kubernetes中的RBAC

  此时把角色改为集群角色:ClusterRole,并重新绑定服务账户:

Kubernetes中的RBAC

  此时该服务账户已经具备集群角色权限,访问集群资源:NameSpace

 kubectl get ns --as system:serviceaccount:default:solinx

Kubernetes中的RBAC

参考资料:

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

文章首发地址:Solinx

http://www.solinx.co/archives/1233