德赢体育平台手机版德赢体育平台手机版


vwin德赢手机网

kubernetes实战(八):k8s集群安全机制RBAC

1、基本概念

  RBAC(Role-Based Access Control,基于角色的访问控制)在k8s v1.5中引入,在v1.6版本时升级为Beta版本,并成为kubeadm安装方式下的默认选项,相对于其他访问控制方式,新的RBAC具有如下优势:

  - 对集群中的资源和非资源权限均有完整的覆盖

    整个RBAC完全由几个API对象完成,同其他API对象一样,可以用kubectl或API进行操作

    可以在运行时进行调整,无需重启API Server

  要使用RBAC授权模式,需要在API Server的启动参数中加上--authorization-mode=RBAC

  

2、RBAC原理和用法

2.1 RBAC的API资源对象说明

  RBAC引入了4个新的顶级资源对象:Role、ClusterRole、RoleBinding、ClusterRoleBinding。同其他API资源对象一样,用户可以使用kubectl或者API调用等方式操作这些资源对象。

  - 角色(Role)

    一个角色就是一组权限的集合,这里的权限都是许可形式的,不存在拒绝的规则。在一个命名空间中,可以用角色来定义一个角色,如果是集群级别的,就需要使用ClusterRole了。

    角色只能对命名空间内的资源进行授权,下面的例子中定义的角色具备读取Pod的权限:

kind: RoleapiVersion: rbac.authorization.k8s.io/v1betalmetadata: namespace: default name: pod-readerrules:- apiGroups: [""] # 空字符串表示核心API群 resource: ["pods"] verbs: ["get", "watch", "list"]

    rules中的参数说明:

    - apiGroup:支持的API组列表,例如:APIVersion: batch/v1、APIVersion: extensions:v1betal、apiVersion:apps/v1betal等

      resources:支持的资源对象列表,例如:pods、deployments、jobs等

      verbs:对资源对象的操作方法列表,例如:get、watch、list、delete、replace、patch等

 

  - 集群角色(ClusterRole)

    集群角色除了具有和角色一致的命名空间内资源的管理能力,因其集群级别的范围,还可以用于以下特殊元素的授权。

    - 集群范围的资源,例如Node

      非资源型的路径,例如/healthz

      包含全部命名空间的资源,例如pods

    下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets:

kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1betalmetadata: # name: secret-reader # ClusterRole不受限于命名空间,所以省略了namespace name的定义rules:- apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]

  - 角色绑定(RoleBinding)和集群角色绑定(ClusterRoleBinding)

    角色绑定或集群角色绑定用来把一个角色绑定到一个目标上,绑定目标可以是User、Group或者Service Account。使用RoleBinding为某个命名空间授权,ClusterRoleBinding为集群范围内授权。

    RoleBinding可以引用Role进行授权,下例中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane,可以让jane用户读取default命名空间的Pod:

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1betalmetadata: name: read-pods namespace: defaultsubjects:- kind: User name: jane apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

    RoleBinding也可以引用ClusterRole,对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组角色(ClusterRole),然后在多个命名空间中重复使用这些ClusterRole。

    使用RoleBinding绑定集群角色secret-reader,使dave只能读取development命名空间中的secret:

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1betalmetadata: name: read-secrets namespace: developmentsubjects:- kind: User name: dave apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

    集群角色绑定中的角色只能是集群角色,用于进行集群级别或者对所有命名空间都生效的授权。

    允许manager组的用户读取任意namespace中的secret

kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1betalmetadata: name: read-secrets-globalsubjects:- kind: Group name: manager apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

 

2.2 对资源的引用方式

  多数资源可以用其名称的字符串来表达,也就是Endpoint中的URL相对路径,例如pods。然后,某些Kubernetes API包含下级资源,例如Pod的日志(logs)。Pod日志的Endpoint是GET /api/v1/namespaces/{namespaces}/pods/{name}/log。

  Pod是一个命名空间内的资源,log就是一个下级资源。要在一个RBAC角色中体现,则需要用斜线/来分割资源和下级资源。若想授权让某个主体同时能够读取Pod和Pod log,则可以配置resources为一个数组:

kind: RoleapiVersion: rbac.authorization.k8s.io/v1betalmetadata: namespace: default name: pod-and-pod-logs-readerrules:- apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list"]

  资源还可以通过名字(ResourceName)进行引用。在指定ResourceName后,使用get、delete、update、patch动词的请求,就会被限制在这个资源实例范围内。例如下面的声明让一个主体只能对一个叫my-configmap的configmap进行get和update操作:

kind: RoleapiVersion: rbac.authorization.k8s.io/v1betalmetadata: namespace: default name: configmap-updaterrules:- apiGroups: [""] resources: ["configmap"] resourceNames: ["my-configmap"] verbs: ["update", "get"]

 

2.3 常见的角色(Role)示例

  - 允许读取核心API组中Pod的资源:

rules:- apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]

  - 允许读写"extensions"和"apps"两个API组中的deployment资源

rules:- apiGroups: ["extensions", "apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

  - 允许读写pods及读写jobs

rules:- apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]- apiGroups: ["batch", "extensions"] resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

  - 允许读取一个名为my-config的ConfigMap(必须绑定到一个RoleBinding来限制到一个namespace下的ConfigMap):

rules:- apiGroups: [""] resources: ["configmaps"] resourceNames: ["my-config"] verbs: ["get"]

  - 读取核心组的node资源(Node属于集群级别的资源,必须放在ClusterRole中,并使用ClusterRoleBinding进行绑定):

rules:- apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"]

   - 允许对非资源端点/healthz及其所有子路径进行GET/POST操作(必须使用ClusterRole和ClusterRoleBinding):

rules:- nonResourceURLs: ["/healthz", "/healthz/*"] verbs: ["get", "post"]

 

2.4 常用的角色绑定

  - 用户名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命名空间中的默认Service Account

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

  - qa命名空间中的所有Service Account

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

  - 所有Service Account

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

  - 所有认证用户

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

  - 所有未认证用户

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

  - 全部用户

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

 

2.5 默认的角色和角色绑定

  API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象,其中很多是以system:为前缀的,以表明这些资源属于基础架构,对这些对象的改动可能造成集群故障。

  所有默认的ClusterRole和RoleBinding都会用标签kubernetes.io/bootstrapping=rbac-defaults进行标记。

  常见的系统角色如下:

  有些默认角色不是以system:为前缀的,这部分角色是针对用户的,其中包含超级用户角色cluster-admin,有的用于集群一级的角色cluster-status,还有针对namespace的角色admin、edit、view

  常见的用户角色如下:

  - 核心Master组件角色

 

 2.6 授权注意事项:预防提权和授权初始化

  RBAC API拒绝用户利用编辑角色或者角色绑定的方式进行提权。这一限制是在API层面做出的,因此即使RBAC没有启用也仍然有效。

  用户只能在拥有一个角色的所有权限,且与该角色的生效范围一致的前提下,才能对角色进行创建和更新。例如用户user-1没有列出集群中所有secret的权限,就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色,需要以下权限:

  - 为其授予一个允许创建/更新Role或ClusterRole资源对象的角色;

    为用户授予角色,要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或者集群角色,则该API调用会被禁止。

  如果一个用户的权限包含了一个角色的所有权限,那么就可以为其创建和更新角色绑定;或者如果被授予了针对某个角色的绑定授权,则也有权完成此操作。

  例如:user1没有列出集群内所有secret的权限,就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定,则需要有如下做法:

  - 为其授予一个允许创建和更新角色绑定或者集群角色绑定的角色

    为其授予绑定某一角色的权限,有隐式或显式两种方法

    - 隐式:让其具有所有该角色的权限

    - 显式:让用户授予针对该角色或集群角色绑定操作的权限

  让user-1有对user-1-namespace命名空间中的其他用户授予admin、edit及view角色

apiVersion: rbac.authorization.k8s.io/v1betalkind: ClusterRolemetadata: name: role-grantorrules:- apiGroups: ["rbac.authorization.k8s.io"] resources: ["rolebindings"] verbs: ["create"]- apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["bind"] resourceNames: ["admin", "edit", "view"]---apiVersion: rbac.authorization.k8s.io/v1betalkind: RoleBindingmetadata: name: role-grantor-binding namespace: user-1-namespaceroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: role-grantorsubjects:- apiGroup: rbac.authorization.k8s.io kind: User name: user-1

  在进行第一个角色和角色绑定时,必须让初始用户具备其尚未被授予的权限,要进行初始的角色和角色绑定设置,有以下两种方法:

  - 使用属于system:masters组的身份,这一群组默认具有cluster-admin这一超级角色的绑定。

    如果API Server以--insecure-port参数运行,则客户端通过这个非安全端口进行接口调用,这一端口没有认证鉴权的限制。

 

, 1, 0, 9);

欢迎阅读本文章: 廉洁

德赢vwin手机

vwin德赢手机网