kubernetes RBAC认证

在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。

  • 从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。
  • 从1.8开始,RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC,启用RABC。
  • 在RABC API中,通过如下的步骤进行授权:
    1. 定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;
    2. 绑定角色:将主体与角色进行绑定,对用户进行访问授权。

Role和ClusterRole

  • 在RBAC API中,角色包含代表权限集合的规则;
  • 通过Role定义在一个命名空间中的角色,一个角色只能被用来授予访问单一命令空间中的资源;
# 定义pod-reader角色,只能在default命名空间对pod进行get、watch、list操作
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]                  # ""表示核心API组
  resources: ["pods"]                            # 明确资源类型
  verbs: ["get", "watch", "list"]  # 可用操作方法
  • 通过ClusterRole定义集群范围的角色,集群角色(ClusterRole)能够被授予如下资源的权限:
    • 集群范围的资源(类似于Node)
    • 非资源端点(类似于”/healthz”)
    • 集群中所有命名空间的资源(类似Pod)
# 定义secret-reader集群角色,能在集群范围内对secrets进行get、watch、list操作
kind:ClusterRole
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:secret-reader
rules:
- apiGroups:[""]
  resources:["secrets"]
  verbs:["get","watch","list"]

RoleBinding和ClusterRoleBinding

  • 角色绑定用于将角色与一个或一组用户进行绑定,从而实现将对用户进行授权的目的;
  • 主体分为用户、组和服务帐户;
  • 角色绑定只能引用同一个命名空间下的角色;
# 定义read-pods角色绑定,将default下角色pod-reader和用户jane进行绑定,使用户jane能访问default下pod
kind:RoleBinding
apiVersion:rbac.authorization.k8s.io/v1
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
  • 角色绑定也可以通过引用集群角色授予访问权限;
# 为用户dave授予在development命令空间下secret-reader的权限
kind:RoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets
  namespace:development
subjects:
- kind:User
  name:dave
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io
  • 集群角色可以被用来在集群层面和整个命名空间进行授权。
# 为用户manager授予集群下查看secret-reader权限
kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets-global
subjects:
- kind:Group
  name:manager
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

resources

在Kubernets中,主要的资源包括:Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMaps等。另外,有些资源下面存在子资源,例如:Pod下就存在log子资源:pods/log

subjects

RBAC授权中的主体可以是组,用户或者服务帐户。

  • 用户通过字符串表示,比如“alice”、 “bob@example.com”等,具体的形式取决于管理员在认证模块中所配置的用户名。
  • system:被保留作为用来Kubernetes系统使用,因此不能作为用户的前缀。
  • 组也有认证模块提供,格式与用户类似。
# 名称为 “alice@example.com”用户:
subjects:
- kind:User
  name:"alice@example.com"
  apiGroup:rbac.authorization.k8s.io
# 名称为“frontend-admins”的组:
subjects:
- kind:Group
  name:"frontend-admins"
  apiGroup:rbac.authorization.k8s.io
# 在kube-system命名空间中,名称为“default”的服务帐户:
subjects:
- kind:ServiceAccount
  name:default
  namespace:kube-system
# 在“qa”命名空间中,所有的服务帐户:
subjects:
- kind:Group
  name:system:serviceaccounts:qa
  apiGroup:rbac.authorization.k8s.io
# 所有的服务帐户:
subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.io
# 所有被认证的用户 (version 1.5+):
subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
# 所有未被认证的用户 (version 1.5+):
subjects:
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io
# 所有用户(version 1.5+):
subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

常用使用场景

命名空间管理员权限

为组织或者个人分配命名空间所有权

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-ns-user
  namespace: default                # 修改为实际ns
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-ns-user
  namespace: default                # 修改为实际ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin               # k8s预置的权限
subjects:
- kind: ServiceAccount
  name: admin-ns-user
  namespace: default                # 修改为实际ns
命名空间只读权限

为组织或个人分配浏览权限

apiVersion: v1
kind: ServiceAccount
metadata:
  name: view-ns-user
  namespace: default                # 修改为实际ns
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: view-ns-user
  namespace: default                # 修改为实际ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view                                # k8s预置的权限
subjects:
- kind: ServiceAccount
  name: view-ns-user
  namespace: default                # 修改为实际ns
集群管理员权限

系统管理员或对接应用权限

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kube-system        # 修改为实际使用的ns
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin               # k8s预置的权限
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kube-system        # 修改为实际使用的ns
集群只读权限
apiVersion: v1
kind: ServiceAccount
metadata:
  name: view-user
  namespace: kube-system        # 修改为实际使用的ns
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view                                # k8s预置的权限
subjects:
- kind: ServiceAccount
  name: view-user
  namespace: kube-system        # 修改为实际使用的ns
自由组合权限

主要在于Role或ClusterRole中rules的编辑,自由分配权限,可实现任何场景的权限分配

apiVersion: v1
kind: ServiceAccount
metadata:
  name: customize-user
  
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: customize-user
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "update"]
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["volumeattachments"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "delete", "update"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: customize-user
subjects:
  - kind: ServiceAccount
    name: customize-user
    namespace: default
roleRef:
  kind: ClusterRole
  name: customize-user
  apiGroup: rbac.authorization.k8s.io 

kubectl使用

  • kubectl create rolebinding
    在指定的命名空间中进行角色绑定:
# 在“acme”命名空间中,将“admin”集群角色授予“bob”用户:
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
# 在“acme”命名空间中,将“admin”集群角色授予“acme:myapp”服务帐户:
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
  • kubectl create clusterrolebinding
    在整个集群中进行角色绑定:
# 在整个集群中,授予”cluster-admin”集群角色给”root”用户:
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
# 在整个集群中,授予”system:node”集群角色给“kubelet”用户:
kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet
# 在整个集群中,授予”view”集群角色给”acme:myapp”服务帐户:
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
posted @ 2020-10-19 20:25  longtds  阅读(125)  评论(0编辑  收藏  举报