K8S认证、授权与准入控制(RBAC)详解
相关推荐
本文的kubernetes环境:https://blog.51cto.com/billy98/2350660
RBAC官方文档:https://kubernetes.io/docs/reference/access-authn-authz/rbac/
前言
- RBAC (Role-Based Access Control,基于角色的访问控制)是一种新型、灵活且使用广泛的访问控制机制,它将权限授予“角色”(role)之上,这一点有别于传统访问控制机制中 将权限直接赋予使用者的方式,简单点来说就是将权限绑定到role中,然后用户和role绑定,这样用户就拥有了和role一样的权限。
- 在任何将资源或服务提供给有限使用者的系统上,认证和授权都是两个必不可少的功 能,认证用于身份鉴别,而授权则实现权限分派 。 Kubemetes 以插件化的方式实现了这两种 功能,且分别存在多种可用的插件。 另外,它还支持准入控制机制,用于补充授权机制以实现更精细的访问控制功能 。
- API Server 作为 Kubernetes 集群系统的网关,是访问及管理资源对象的唯一人口,所有需要访问集群资源的组件,以及此前使用的 kubectl 命令等都要经由此网关进行集群访问和管理。
- RBAC使用
rbac.authorization.k8s.io
API Group 来实现授权决策,允许管理员通过 Kubernetes API 动态配置策略,要启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,都默认开启了RBAC,可以通过查看 Master 节点上 apiserver 的静态Pod定义文件:[root@node-01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml ··· - --authorization-mode=Node,RBAC ···
- 如果是二进制的方式搭建的集群,添加这个参数过后,记得要重启 apiserver 服务。
RBAC API资源对象
Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象,允许执行增、删、改、查等操作,比如下面的这下资源:
- Pods
- ConfigMaps
- Deployments
- Nodes
- Secrets
- Namespaces
上面这些资源对象的可能存在的操作有:
- create
- get
- delete
- list
- update
- edit
- watch
- exec
用户账户和用户组
Kubernetes 并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息,它们仅仅用于检验用户是否有权限执行其所请求的操作。
客户端访问API服务的途径通常有三种:kubectl、客户端库或者直接使用 REST接口进行请求。
而可以执行此类请求的主体也被 Kubernetes 分为两类:现实中的“人”和 Pod 对象, 它们的用户身份分别对应于常规用户 (User Account )和服务账号 ( Service Account) 。
- Use Account(用户账号):一般是指由独立于Kubernetes之外的其他服务管理的用 户账号,例如由管理员分发的密钥、Keystone一类的用户存储(账号库)、甚至是包 含有用户名和密码列表的文件等。Kubernetes中不存在表示此类用户账号的对象, 因此不能被直接添加进 Kubernetes 系统中 。
- Service Account(服务账号):是指由Kubernetes API 管理的账号,用于为Pod 之中的服务进程在访问Kubernetes API时提供身份标识( identity ) 。Service Account通常要绑定于特定的命名空间,它们由 API Server 创建,或者通过 API 调用于动创建 ,附带着一组存储为Secret的用于访问API Server的凭据。
Kubernetes 有着以下几个内建的用于特殊目的的组 。
- system:unauthenticated :未能通过任何一个授权插件检验的账号,即未通过认证测 试的用户所属的组 。
- system :authenticated :认证成功后的用户自动加入的一个组,用于快捷引用所有正常通过认证的用户账号。
- system : serviceaccounts :当前系统上的所有 Service Account 对象。
- system :serviceaccounts :<namespace>:特定命名空间内所有的 Service Account 对象。
Role和ClusterRole
- Role是只作用于命名空间级别的,用于定义命名空间内资源权限集合。
- ClusterRole则用于集群级别的资源权限集合,它们都是标准的 API 资源类型 。
- 一般来说, ClusterRole 的许可授权作用于整个集群,因此常用于控制 Role 无法生效的资源类型,这包括集群级别的资源(如Nodes)、非资源类型的端点(如/healthz)和作用于所有命名空间的资源(例如跨命名空间获取任何资源的权限)。
RoleBinding和ClusterRoleBinding
-
RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上,它隶属于且仅能作用于一个命名空间。绑定时,可以引用同一名称中的Role,也可以引用集群级别的 ClusterRole。
- ClusterRoleBinding则把ClusterRole中定义的许可权限绑定在一个或一组用户之上,它仅可以引用集群级别的ClusterRole。
-
Role、RoleBinding、ClusterRole和ClusterRoleBinding 的关系如图 所示 。
- 一个命名空间中可以包含多个Role和RoleBinding对象,类似地,集群级别也可以同时存在多个ClusterRole和ClusterRoleBinding对 象。而一个账户也可经由RoleBinding ClusterRoleBinding关联至多个角色,从而具有多重许可授权。
下面我们来创建一个User Account,测试访问某些我们授权的资源:
创建k8s User Account
一、创建证书
-
创建user私钥
[root@node-01 ~]# cd /etc/kubernetes/pki/ [root@node-01 pki]# (umask 077;openssl genrsa -out billy.key 2048) Generating RSA private key, 2048 bit long modulus .................................................................................+++ ..................+++ e is 65537 (0x10001)
-
创建证书签署请求
O=组织信息,CN=用户名[root@node-01 pki]# openssl req -new -key billy.key -out billy.csr -subj "/O=jbt/CN=billy"
- 签署证书
[root@node-01 pki]# openssl x509 -req -in billy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out billy.crt -days 365 Signature ok subject=/O=jbt/CN=billy Getting CA Private Key
二、创建配置文件
创建配置文件主要有以下几个步骤:
kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE #集群配置 kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用户配置 kubectl config set-context #context配置 kubectl config use-context #切换context
- --embed-certs=true的作用是不在配置文件中显示证书信息。
- --kubeconfig=/root/billy.conf用于创建新的配置文件,如果不加此选项,则内容会添加到家目录下.kube/config文件中,可以使用use-context来切换不同的用户管理k8s集群。
- context简单的理解就是用什么用户来管理哪个集群,即用户和集群的结合。
创建集群配置
[root@node-01 pki]# kubectl config set-cluster k8s --server=https://10.31.90.200:8443 --certificate-authority=ca.crt --embed-certs=true --kubeconfig=/root/billy.conf Cluster "k8s" set. [root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://10.31.90.200:8443 name: k8s contexts: [] current-context: "" kind: Config preferences: {} users: []
创建用户配置
[root@node-01 pki]# kubectl config set-credentials billy --client-certificate=billy.crt --client-key=billy.key --embed-certs=true --kubeconfig=/root/billy.conf User "billy" set. #查看配置文件 [root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://10.31.90.200:8443 name: k8s contexts: [] current-context: "" kind: Config preferences: {} users: - name: billy user: client-certificate-data: REDACTED client-key-data: REDACTED
创建context配置
[root@node-01 pki]# kubectl config set-context billy@k8s --cluster=k8s --user=billy --kubeconfig=/root/billy.conf Context "billy@k8s" created. #查看配置文件 [root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://10.31.90.200:8443 name: k8s contexts: - context: cluster: k8s user: billy name: billy@k8s current-context: "" kind: Config preferences: {} users: - name: billy user: client-certificate-data: REDACTED client-key-data: REDACTED
切换context
[root@node-01 pki]# kubectl config use-context billy@k8s --kubeconfig=/root/billy.conf Switched to context "billy@k8s". #查看配置文件 [root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://10.31.90.200:8443 name: k8s contexts: - context: cluster: k8s user: billy name: billy@k8s current-context: billy@k8s kind: Config preferences: {} users: - name: billy user: client-certificate-data: REDACTED client-key-data: REDACTED
创建系统用户及k8s验证文件
[root@node-01 ~]# useradd billy #创建什么用户名都可以 [root@node-01 ~]# mkdir /home/billy/.kube [root@node-01 ~]# cp billy.conf /home/billy/.kube/config [root@node-01 ~]# chown billy.billy -R /home/billy/.kube/ [root@node-01 ~]# su - billy [billy@node-01 ~]$ kubectl get pod Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "default" #默认新用户是没有任何权限的。
创建Role
此role只有pod的get、list、watch权限
[root@node-01 rbac]# cat pods-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pods-reader rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch [root@node-01 rbac]# kubectl apply -f pods-reader.yaml role.rbac.authorization.k8s.io/pods-reader created
创建Rolebinding
用户billy和role pods-reader的绑定
[root@node-01 rbac]# cat billy-pods-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: billy-pods-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pods-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: billy [root@node-01 rbac]# kubectl apply -f billy-pods-reader.yaml rolebinding.rbac.authorization.k8s.io/billy-pods-reader created
验证结果
如果没有指定命名空间的话,默认就是default命名空间。
[billy@node-01 ~]$ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-demo-95bd675d5-66xrm 1/1 Running 0 18d tomcat-5c5dcbc885-7vr68 1/1 Running 0 18d [billy@node-01 ~]$ kubectl -n kube-system get pod Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "kube-system"
所以我们是可以查看查看default命名空间的pod,但是其他空间的pod是无法查看的。
创建ClusterRole
[root@node-01 rbac]# cat cluster-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-reader rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch [root@node-01 rbac]# kubectl apply -f cluster-reader.yaml clusterrole.rbac.authorization.k8s.io/cluster-reader created
创建ClusterRoleBinding
[root@node-01 rbac]# cat billy-read-all-pods.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: billy-read-all-pods roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: billy [root@node-01 rbac]# kubectl apply -f billy-read-all-pods.yaml clusterrolebinding.rbac.authorization.k8s.io/billy-read-all-pods created
验证结果
创建了ClusterRole和ClusterRoleBinding后就可以看到所有命名空间的pod了。
[billy@node-01 ~]$ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-demo-95bd675d5-66xrm 1/1 Running 0 18d tomcat-5c5dcbc885-7vr68 1/1 Running 0 18d [billy@node-01 ~]$ kubectl -n kube-system get pod NAME READY STATUS RESTARTS AGE canal-gd4qn 2/2 Running 0 21d cert-manager-6464494858-wqpnb 1/1 Running 0 18d coredns-7f65654f74-89x69 1/1 Running 0 18d coredns-7f65654f74-bznrl 1/1 Running 2 54d ...
ServiceAccount
至于ServiceAccount怎么授权,其实相对user account来说更简单,只需先创建ServiceAccount,然后创建role或者ClusterRole,最后在RoleBinding或ClusterRoleBinding绑定即可。以下简单做一个示例,就不在显示结果了,大家可以自己去验证。
创建SA
kubectl create sa billy-sa
创建Role
[root@node-01 rbac]# cat billy-sa-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: billy-sa-role rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch
创建Rolebinding
将billy-sa和billy-sa-role的绑定
[root@node-01 rbac]# cat billy-sa-rolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: billy-sa-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: billy-sa-role subjects: - kind: ServiceAccount name: billy-sa
验证结果
创建完SA之后系统会自动创建一个secret,我们可以获取这个secret里面的token去登录dashboard,就可以看到相应有权限的资源。
kubectl get secret billy-sa-token-9rc55 -o jsonpath={.data.token} |base64 -d
还可以在创建pod时在pod的spec里指定serviceAccountName,那么这个pod就拥有了对应的权限,具体的就不在演示了。
本次的分享就到此,如有问题欢迎在下面留言交流,希望大家多多关注和点赞,谢谢!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
CentOS(5.8/6.4)linux生产环境若干优化实战(实用篇)
下面我就为大家简单讲解几点关于Linux系统安装后的基础优化操作。 注意:本次优化都是基于CentOS(5.8/6.4)。关于5.8和6.4两者优化时的小区别,我会在文中提及的。 优化条目: 修改ip地址、网关、主机名、DNS等 关闭selinux,清空iptables 添加普通用户并进行sudo授权管理 更新yum源及必要软件安装 定时自动更新服务器时间 精简开机自启动服务 定时自动清理/var/spool/clientmqueue/目录垃圾文件,放置inode节点被占满 变更默认的ssh服务端口,禁止root用户远程连接 锁定关键文件系统 调整文件描述符大小 调整字符集,使其支持中文 去除系统及内核版本登录前的屏幕显示 内核参数优化 1、修改ip地址、网关、主机名、DNS等 [root@localhost ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 #网卡名字 BOOTPROTO=static #静态IP地址获取状态 如:DHCP表示自动获取IP地址 IPADDR=192.168.1.113 #IP地址 ...
- 下一篇
可照搬实施的商超高可用方案:proxmox + haproxy 等
现状 存在大量的单点问题:每个门店一个物理服务器,中心机房多个服务器。门店服务器故障,营业受影响;中心机房服务器故障,门店的非现金业务(银行卡刷卡、微信支付、支付宝等)受影响 总体思路 撤销每个门店的服务器,保证门店网络的可靠性(多线路接入、4G终端设备等),服务器集中到中心机房,构建更高可用性的数据平台。 基本目标 高可用性:最小的停机时间,部分硬件损坏不对正常业务产生影响。 可扩展性:随业务增加,可不停止业务进行容量扩充,也不改变现有的系统架构。 可视化运维:随时掌握系统的运行情况,并以集中、直观的方式进行展示。 低成本:充分利用现有资源、合理规划,使整个平台成本可控且满足实际需求。 架构组成 本方案架构由负载均衡、超融合私有云、监控平台以及备份系统组合而成。 Ø 负载均衡 负责将门店终端的请求按一定的算法,转发到多个相同的后端应用。负载均衡实际包含三个功能:负载均衡、健康检查及失败切换。 负载均衡:多个后端分担负载,以支持更大规模的访问及业务请求; 健康检查:后端服务某一个或者几个出现故障,负载均衡器会自动把故障系统从转发队列里面自动清除;后端服务恢复正常后,其又会自动加入到转发...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Mario游戏-低调大师作品
- CentOS6,CentOS7官方镜像安装Oracle11G