转入已备案网站网页制作服务的公司

当前位置： 首页 > news >正文

转入已备案网站,网页制作服务的公司,行业数据分析网站,购物网站 开店4 RBAC授权 4.1 什么是RBAC 在Kubernetes中#xff0c;所有资源对象都是通过API进行操作#xff0c;他们保存在etcd里。而对etcd的操作我们需要通过访问kube-apiserver来实现#xff0c;上面的Service Account其实就是APIServer的认证过程#xff0c;而授权的机制是通过RBA… 4 RBAC授权 4.1 什么是RBAC 在Kubernetes中所有资源对象都是通过API进行操作他们保存在etcd里。而对etcd的操作我们需要通过访问kube-apiserver来实现上面的Service Account其实就是APIServer的认证过程而授权的机制是通过RBAC基于角色的访问控制实现。 RBAC(Role Base Access Control)基于角色的访问控制其实就是将资源的操作权限授予给指定的角色而后将用户加入该角色那么该用户则拥有了对应角色的权限。 RBAC有四个资源对象分别是 Role、ClusterRole、RoleBinding、ClusterRoleBinding。 举例: 希望qingchen用户能够获取所有Pod的列表 1、首先定义角色然后定义角色权限规则资源: POd操作权限: get,list 2、然后定义角色绑定将qingchen绑定至该角色然后qingchen就拥有了该角色的权限进而就能获取Pod信息 4.2 RBAC角色与集群角色 Kubernetes系统的RBAC授权插件将角色分为了Role和ClusterRole两类: Role: 进作用于名称空间级别用于承载名称空间级别内的资源权限集合 ClusterRole: 作用于集群乏味能够同时承载名称空间和集群级别的资源权限集合 Kubernetes利用Role和ClusterRole两类角色来赋予对应的权限同时也需要用到另外两类资源Rolebinding和ClusterRolebinding来完成用户与角色之间的绑定关系。 注意: RoleBinding除了可以绑定Role以外还可以绑定ClusterRole但它的权限还是限制在名称空间级别; 这种方式有着特定的应用场景: 比如: 希望在三个名称空间中都创建一个管理员身份那么我们就需要创建3个role和3个rolebinding 但是: 我们可以定义一个clusterrole然后通过rolebinding绑定就完成了也就不需要重复创建很多的role 4.3Role:角色 一组权限的集合在一个命名空间中可以用其来定义一个角色只能对命名空间内的资源进行授权。如果是集群级别的资源则需要使用ClusterRole。例如定义一个角色用来读取 Pod 的权限 登录后复制 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: rbac name: pod-read rules:

• apiGroups: [] resources: [pods] resourceNames: [] verbs: [get,watch,list]rules 中的参数说明 1、apiGroups支持的API组列表例如apiVersion: batch/v1等 2、resources支持的资源对象列表例如pods、deplayments、jobs等 3、resourceNames: 指定resource的名称 4、verbs对资源对象的操作方法列表。 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16. 4.4ClusterRole:集群角色 具有和角色一致的命名空间资源的管理能力还可用于以下特殊元素的授权 1、集群范围的资源例如Node 2、非资源型的路径例如/healthz 3、包含全部命名空间的资源例如Pods 例如定义一个集群角色可让用户访问任意 登录后复制 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secrets-clusterrole rules:
• apiGroups: [] resources: [secrets] verbs: [get,watch,list] 1.2.3.4.5.6.7.8. 4.5RoleBinding:角色绑定、ClusterRolebinding:集群角色绑定  角色绑定和集群角色绑定用于把一个角色绑定在一个目标上可以是 UserGroupService Account使用RoleBinding为某个命名空间授权使用ClusterRoleBinding为集群范围内授权。 例如将在 rbac 命名空间中把 pod-read 角色授予用户 es 登录后复制 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-read-bind namespace: rbac subjects:
• kind: User name: es apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-read apiGroup: rbac.authorizatioin.k8s.io 1.2.3.4.5.6.7.8.9.10.11.12.13. RoleBinding也可以引用ClusterRole对属于同一命名空间内的ClusterRole定义的资源主体进行授权 例如es 能获取到集群中所有的资源信息 登录后复制 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: es-allresource namespace: rbac subjects:
• kind: User name: es apiGroup: rbac.authorization.k8s.io roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin 1.2.3.4.5.6.7.8.9.10.11.12.13. 集群角色绑定的角色只能是集群角色用于进行集群级别或对所有命名空间都生效的授权 例如允许manager组的用户读取所有namaspace的secrets 登录后复制 apiVersion: rabc.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secret-global subjects:
• kind: Group name: manager apiGroup: rabc.authorization.k8s.io ruleRef: kind: ClusterRole name: secret-read apiGroup: rabc.authorization.k8s.io 1.2.3.4.5.6.7.8.9.10.11.12. 4.6 资源的引用方式 多数资源可以用其名称的字符串表示也就是Endpoint中的URL相对路径例如pod中的日志是GET /api/v1/namaspaces/{namespace}/pods/{podname}/log 如果需要在一个RBAC对象中体现上下级资源就需要使用“/”分割资源和下级资源。 例如若想授权让某个主体同时能够读取Pod和Pod log则可以配置 resources 为一个数组 登录后复制 apiVersion: rabc.authorization.k8s.io/v1 kind: Role metadata: name: logs-reader namespace: default rules:
• apiGroups: [] resources: [pods,pods/log] verbs: [get,list] 1.2.3.4.5.6.7.8.9. 资源还可以通过名称(ResourceName)进行引用在指定ResourceName后使用get、 delete、update、patch请求就会被限制在这个资源实例范围内 例如下面的声明让一个主体只能对名为my-configmap的Configmap进行get和update操作 登录后复制 apiVersion: rabc.authorization.k8s.io/v1 kind: Role metadata: namaspace: default name: configmap-update rules:
• apiGroups: [] resources: [configmap] resourceNames: [my-configmap] verbs: [get,update] 1.2.3.4.5.6.7.8.9.10. 4.7RBAC场景实践 4.7.1 kubectl命令行工具创建资源对象 (1)在命名空间rbac中为用户es授权admin ClusterRole kubectl create rolebinding bob-admin-binding –clusterroleadmin –useres –namespacerbac (2)在命名空间rbac中为名为myapp的Service Account授予 view ClusterRole kubctl create rolebinding myapp-role-binding –clusterroleview –serviceaccountrbac:myapp –namespacerbac (3)在全集群范围内为用户root授予cluster-admin ClusterRole kubectl create clusterrolebinding cluster-binding –clusterrolecluster-admin –userroot (4)在全集群范围内为名为myapp 的 Service Account 授予 view ClusterRole kubectl create clusterrolebinding service-account-binding –clusterroleview –serviceaccountmyapp yaml 文件进行 rbac 授权https://kubernetes.io/zh/docs/reference/access-authnauthz/rbac/ 4.7.2实践场景-1 场景说明: 赋予qingchen用户对default名称空间拥有Pod的读取权限 1、创建role角色设定对应的规则 登录后复制 #命令方式 kubectl create role default-pod-reader
  –resourcepod
  –verbget,list,watch
  –namespacedefault#yaml方式 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:name: default-pod-readernamespace: default rules:
• apiGroups:- resources:- podsverbs:- get- list- watch 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21. 2、创建rolebinding角色绑定将qingchen绑定至对应的role上 登录后复制 #命令方式 kubectl create rolebinding qingchen-default-pod-reader
  –roledefault-pod-reader
  –userqingchen
  –namespacedefault#yaml方式 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:name: qingchen-default-pod-readernamespace: default roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: default-pod-reader subjects:
• apiGroup: rbac.authorization.k8s.iokind: Username: qingchen 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20. 3、使用qingchen用户验证权限 #非default名称空间访问会报错 4.7.3实践场景-2 场景说明: 赋予qingchen用户对所有名称空间拥有Pod的读写权限(ClusterRole、ClusterRoleBinding) 1、创建clusterrole 登录后复制 #命令方式 kubectl create clusterrole cluster-pod-reader
  –resourcepod
  –verbget,list,watch#yaml方式 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:name: cluster-pod-reader rules:
• apiGroups:- resources:- podsverbs:- get- list- watch 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19. 2、创建clusterrolebinding并绑定qingchen用于至对应的clusterrole 登录后复制 #命令方式 kubectl create clusterrolebinding cluster-pod-reader-qingchen
  –clusterrolecluster-pod-reader
  –userqingchen#yaml方式 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:name: cluster-pod-reader-qingchen roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-pod-reader subjects:
• apiGroup: rbac.authorization.k8s.iokind: Username: qingchen 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18. 3、使用qingchen用户验证权限 kubectl get pod –contextqingchenkubernetes kubectl get pod -n kube-system –contextqingchenkubernetes #任何名称空间都可以查看但没有删除权限 4.7.4实践场景-3 场景说明: 赋予qingchen用户对default名称空间拥有管理员权限 系统内置了一个ClusterRole:admin的集群管理员我们可以通过rolebinding引用Cluster:admin集群角色该引用会造成用户仅对rolebinding所在的名称空间有管理员权限(因为rolebinding仅能作用在名称空间)。 1、删除此前的绑定避免权限受到干扰 kubectl delete clusterrolebinding cluster-pod-reader-qingchen 2、创建RoleBinding引用Cluster-role 登录后复制 kubectl create rolebinding default-admin-qingchen
  –clusterroleadmin
  –userqingchen
  –namespacedefault 1.2.3.4. 3、验证qingchen用户权限 #能对default名称空间进行增删改查对其他名称空间毫无权限 4.8内置的ClusterRole Kubernetes系统内置了一组默认的ClusterRole和ClusterRoleBinding资源预留给系统使用其中大多数以system:为前缀。还有一些不以system:为前缀的 ClusterRole是面向用户设计的比如: 集群管理员角色cluster-admin、admin、edit、view掌握这些默认的内置角色资源有助于按需创建用户并分配相应的权限。 4.8.1 Cluster-admin分析 内置的cluster-admin资源拥有管理集群所有资源的权限而内置的cluster-admin将该角色分配给了system:master组这意味着所有加入该组的用户都将自动具有集群的超级管理员权限。 在使用kubeadm安装集群时它自动创建配置文件/etc/kubernetes/admin.conf中定义的用户为kubernetes-admin而该用户使用数字证书Subject属性值为/Osystem:masters。所以APIServer会在成功验证该用户的身份之后将其识别为system:masters用户组的成员。 分析过程如下 1、查看cluster-admin角色绑定关系可以看到cluster-admin这个角色绑定的system.masters 2、system:masters这个组名称并非人为定义而是证书生成的 openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -text -noout 注意: 在创建证书时可以将用户绑定到systemmasters、组用户会自动继承组的权限 4.8.2 Cluster-admin实践 创建一个k8s-dream用户然后将该用户加入到system:masters组中验证是否拥有集群管理员权限 1、创建证书私钥文件 登录后复制 mkdir /root/k8scerts -p umask 077 openssl genrsa -out /root/k8scerts/k8s-dream.key 2048 1.2.3. 2、创建证书签署请求文件CN为指定的用户名O为指定的组名称 登录后复制 openssl req -new
  -key /root/k8scerts/k8s-dream.key
  -out /root/k8scerts/k8s-dream.csr
  -subj /CNk8s-dream/Osystem:masters 1.2.3.4. 3、使用kubernetes-ca的身份对文件进行签署 登录后复制 openssl x509 -req -days 3650
  -in /root/k8scerts/k8s-dream.csr
  -CA /etc/kubernetes/pki/ca.crt
  -CAkey /etc/kubernetes/pki/ca.key
  -CAcreateserial
  -out /root/k8scerts/k8s-dream.crt 1.2.3.4.5.6. 4、根据x509数字证书及私钥创建身份凭据 登录后复制 kubectl config set-credentials k8s-dream
  –client-certificate/root/k8scerts/k8s-dream.crt
  –client-key/root/k8scerts/k8s-dream.key
  –embed-certstrue 1.2.3.4. 5、配置context上下文以k8s-dream身份凭据访问已定义的Kubernetes集群context名称为k8s-dreamkubernetes 登录后复制 kubectl config set-context k8s-dreamkubernetes
  –clusterkubernetes
  –userk8s-dream 1.2.3. 6、测试k8s-dream是否具备超级管理员权限 kubectl get nodes –contextk8s-dreamkubernetes kubectl get pod -A –contextk8s-dreamkubernetes 4.9 常见角色示例 登录后复制 (1)允许读取核心 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允许读取 Pod 以及读写 job 信息 rules:
• apiGroups: [] resources: [pods] verbs: [get,list,watch]、
• apiVersion: [batch,extensions] resources: [jobs] verbs: get,list,watch,create,update,patch,delete允许读取一个名为 my-config 的 ConfigMap(必须绑定到一个 RoleBinding 来限制到一个Namespace下的 ConfigMap) rules:
• apiGroups: [] resources: [configmap] resourceNames: [my-configmap] 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] 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38. 4.10 常见角色绑定示例 登录后复制 (1)用户名 alice subjects:
• kind: User name: alice apiGroup: rbac.authorization.k8s.io (2)组名 alice subjects:
• kind: Group name: alice apiGroup: rbac.authorization.k8s.io (3)kube-system 命名空间中默认 Service Account subjects:
• kind: ServiceAccount name: default namespace: kube-system (4)qa 命名空间中的所有 Service Account subjects:
• kind: Group name: system:serviceaccounts:qa apiGroup: rbac.authorization.k8s.io (5)所有 Service Account subjects:
• kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io (6)所有认证用户 subjects:
• kind: Groupname: system:authenticated apiGroup: rbac.authorization.k8s.io (7)所有未认证用户 subjects:
• kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io (8)全部用户 subjects:
• kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io
• kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50. 4.11 限制不同的用户操作k8s集群 登录后复制 ssl 认证 生成一个证书 (1)生成一个私钥 cd /etc/kubernetes/pki/ (umask 077; openssl genrsa -out lucky.key 2048) (2)生成一个证书请求 openssl req -new -key lucky.key -out lucky.csr -subj /CNlucky (3)生成一个证书 openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650 在 kubeconfig 下新增加一个 lucky 这个用户 (1)把 lucky 这个用户添加到 kubernetes 集群中可以用来认证 apiserver 的连接 kubectl config set-credentials lucky –client-certificate./lucky.crt –client-key./lucky.key –embed-certstrue (2)在 kubeconfig 下新增加一个 lucky 这个账号 kubectl config set-context luckykubernetes –clusterkubernetes –userlucky (3)切换账号到 lucky默认没有任何权限 kubectl config use-context luckykubernetes kubectl config use-context kubernetes-adminkubernetes 这个是集群用户有任何权限 把user这个用户通过rolebinding绑定到clusterrole上授予权限,权限只是在lucky这个名称空间有效 (1)把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上 kubectl create ns lucky kubectl create rolebinding lucky -n lucky –clusterrolecluster-admin –userlucky (2)切换到 lucky 这个用户 kubectl config use-context luckykubernetes (3)测试是否有权限 kubectl get pods -n lucky 有权限操作这个名称空间 kubectl get pods 没有权限操作其他名称空间添加一个 lucky 的普通用户 useradd lucky cp -ar /root/.kube/ /home/lucky/ chown -R lucky.lucky /home/lucky/ su - lucky kubectl get pods -n lucky 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.