Kubernetes中的RBAC

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

  在RABC API中,通过如下的步骤进行授权:
  1)定义角色:定义角色时会指定此角色对于资源的访问控制的规则;
  2)定义主体:用户、组和服务帐户
  3)绑定角色:将主体与角色进行绑定,对主体进行访问授权。


                    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

由于只授予了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"

该角色为普通角色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

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

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

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

参考资料:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/

文章首发地址:Solinx
http://www.solinx.co/archives/1233

原文地址:https://www.cnblogs.com/softlin/p/9691639.html

时间: 2024-10-08 21:17:37

Kubernetes中的RBAC的相关文章

Kubernetes 中的pv和pvc

原文地址:http://www.cnblogs.com/leidaxia/p/6485646.html 持久卷 PersistentVolumes 本文描述了 Kubernetes 中的 PersistentVolumes.要求读者有对卷 (volumes) 所有了解. 简介 存储管理跟计算管理是两个不同的问题.PersistentVolume 子系统,对存储的供应和使用做了抽象,以 API 形式提供给管理员和用户使用.要完成这一任务,我们引入了两个新的 API 资源:PersistentVol

实用干货:Kubernetes中的负载均衡全解

很多企业在部署容器的时候都会选择Kubernetes作为其容器编排系统.这是对Kubernetes的可靠性,灵活性和特性广泛的肯定.在这篇文章中,我们将对Kubernetes如何处理一个非常常见且必要的工作--负载均衡,进行深入的解读.在许多非容器环境(即服务器之间的均衡)中,负载均衡是一个相对简单的任务,但当涉及到容器时,就需要一些其他的.特殊的处理. 管理容器 要理解Kubernetes的负载均衡,首先需要了解Kubernetes是如何组建容器的. 容器通常用来执行特定的服务或者一组服务,因

大神教你轻松玩转Docker和Kubernetes中如何运行MongoDB微服务

本文介绍了利用Docker和Kubernetes搭建一套具有冗余备份集合的MongoDB服务,从容器对CI和CD引发的改变入手,讨论了容器技术对MongoDB带来的挑战和机会,然后实战如何部署一套稳定的MongoDB服务,非常的干货 介绍 想尝试在笔记本电脑上运行MongoDB么?希望通过执行一个简单的命令,然后就有一个轻量级.自组织的沙盒么?并可再通过一条命令就可以移除所有的痕迹么? 需要在多个环境中运行相同的应用程序栈?创建自己的容器镜像,使得开发.测试.操作和支持团队启动一份完全相同的环境

如何在Kubernetes中管理有状态应用

在Kubernetes中,StatefulSet被用来管理有状态应用的API对象.StatefulSets在Kubernetes 1.9版本才稳定.StatefulSet管理Pod部署和扩容,并为这些Pod提供顺序和唯一性的保证.与Deployment相似的地方是,StatefulSet基于spec规格管理Pod:与Deployment不同的地方是,StatefulSet需要维护每一个Pod的唯一身份标识.这些Pod基于同样的spec创建,但互相之间不能替换,每一个Pod都保留自己的持久化标识.

kubernetes中的Pod简述与实践

Pod的概念详细的Pod解释可参考k8s官网,关于Pod的概念主要有以下几点:(1)Pod是kubernetes中你可以创建和部署的最小也是最简的单位.一个Pod代表着集群中运行的一个进程:(2)在Kubrenetes集群中Pod的使用方式:(3)Pod中如何管理多个容器 理解Pod上面已经说了"Pod是kubernetes中你可以创建和部署的最小也是最简的单位.一个Pod代表着集群中运行的一个进程."Pod中封装着应用的容器(有的情况下是好几个容器),存储.独立的网络IP,管理容器如

kubernetes中网络报错问题

系统环境 #系统版本 cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) #kubelet版本 kubelet --version Kubernetes v1.10.0 #selinux状态 getenforce Disabled #系统防火墙状态 systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loade

kubernetes中部署Heketi和GlusterFS(二)

kubernetes中部署Heketi和GlusterFS(二)在上一节中,Heketi的部署方式还不能用于生产环境,因为Heketi Pod的数据并没有持久化,容易导致heketi的数据丢失,Heketi的数据保存在/var/lib/heketi/heketi.db文件中,因此需要把此目录挂载到GlusterFS分布式存储中. 按照上一节的步骤,执行heketi-cli topology load --json=topology-sample.json $ echo $HEKETI_CLI_S

Kubernetes中,通过Service访问Pod快速入门

一.背景 理想状态下,我们可以认为Kubernetes Pod是健壮的.但是,理想与现实的差距往往是非常大的.很多情况下,Pod中的容器可能会因为发生故障而死掉.Deployment等Controller会通过动态创建和销毁Pod来保证应用整体的健壮性.众所周知,每个Pod都拥有自己的IP地址,当新的Controller用新的Pod替代发生故障的Pod时,我们会发现,新的IP地址可能跟故障的Pod的IP地址可能不一致.此时,客户端如何访问这个服务呢?Kubernetes中的Service应运而生

Kubernetes中,两种常见类型的Volume深度实践

一.背景 存储资源在所有计算资源中扮演着十分重要的角色,大部分业务场景下都有可能使用到各类存储资源.在Kubernetes中,系统通过Volume对集群中的容器动态或静态提供存储资源.通常情况下,我们可以认为容器或者Pod的生命周期时短暂的,当容器被销毁时,容器内部的数据也同时被清除.为了持久化保存容器的数据,Kubernetes引入了Volume,类似于Docker的Volume(Docker also has a concept of volumes, though it is somewh