K8s中Service Account和RBAC

这篇具有很好参考价值的文章主要介绍了K8s中Service Account和RBAC。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一.Service Account详解

1.什么是Service Account?

①.ServiceAccount(服务账户)是Kubernetes集群中的一种资源对象,用于为Pod或其他资源提供身份验证和授权,以便它们能够与Kubernetes API进行交互。

②.ServiceAccount是Kubernetes中用于管理Pod身份验证和授权的重要资源,它使得Pod能够在集群中具有独立的身份,从而实现更精细的权限控制和安全策略。

③. Service Account它并不是给kubernetes集群的用户使用的,而是给pod里面的进程使用的,它为pod提供必要的身份认证。----专门为pod里面的进程和apiserver通信提供认证的。

2.Service account与User account区别:

1. User account是为人设计的,而service account则是为Pod中的进程调用Kubernetes API或其他外部服务而设计的

2. User account是跨namespace的,而service account则是仅局限它所在的namespace;

3. 每个namespace都会自动创建一个default service account    

4. Token controller检测service account的创建,并为它们创建secret

3.Service Account 实列

角色和sa需要rolebinding进行绑定,然后sa和pod进行绑定从而达到对资源限制的目的。

创建Service Account

创建sa是也会自动创建一个secret

# vim mysa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysa
  namespace: default


#应用
# kubectl apply -f mysa.yaml

查看mysa和自动创建的secret

#查看sa
[root@kube-master kubernetes]# kubectl  get sa mysa
NAME   SECRETS   AGE
mysa   1         22h

#查看secret
[root@kube-master kubernetes]# kubectl  get secret
NAME                  TYPE                                  DATA   AGE
default-token-j48pd   kubernetes.io/service-account-token   3      4d20h
mysa-token-zw9b9      kubernetes.io/service-account-token   3      22h

创建角色和绑定

[root@kube-master kubernetes]# vim role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: mysa-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: mysa-binding
  namespace: default
subjects:                 #定义对那个主体进行操作,
- kind: ServiceAccount
  name: mysa
  namespace: default
roleRef:                    #定义使用哪个角色
  kind: Role
  name: mysa-role
  apiGroup: rbac.authorization.k8s.io


#####导入
kubectl apply -f role.yaml

使用mysa的sa资源配置pod

[root@kube-master kubernetes]# vim mysa-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mysa-pod
spec:
  serviceAccountName: mysa   # 给pod指定Service Account
  containers:
  - name: app
    image: 10.36.192.206:8088/newrain857/kubectl
    command: ["tail","-f","/dev/null"]
    

###导入
kubectl apply -f mysa-pod.yaml

查看

kubectl  get pod mysa-pod -o  yaml

进入容器测试(可以看到,我们已经成功限制了pod对资源的访问)

[root@kube-master kubernetes]# kubectl  exec -it mysa-pod -c app  /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # 
/ # 
/ # kubectl get pod
NAME            READY   STATUS    RESTARTS        AGE
mysa-pod        1/1     Running   1 (6h20m ago)   22h
mysql           1/1     Running   1 (6h20m ago)   19h
nginx           1/1     Running   1 (6h21m ago)   17h
test-downward   1/1     Running   0               5h39m

##没有给delete权限就无法操作
/ # kubectl delete nginx
error: the server doesn't have a resource type "nginx"

二.RBAC(基于角色的访问控制)

角色绑定用户达到对用户限制的目的

k8s里面有两种用户,一种是User,一种就是service account(服务使用的账号)。
User account是为人设计的属于用户账户(个人使用的账号),此外User Account是跨Namespace的,而ServiceAccount则是仅局限它所在的Namespace。


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

角色

  • Role:授权特定命名空间的访问权限
  • ClusterRole:授权所有命名空间的访问权限

角色绑定

  • RoleBinding:将角色绑定到主体(即subject)
  • ClusterRoleBinding:将集群角色绑定到主体

在K8s中这些资源分属于两个级别,名称空间(role/rolebinding)和集群级别(clusterrole/clusterrolebinding)这两个都是标准的K8s资源,可以直接定义。

rolebinding:将哪个用户绑定到哪个role上
clusterrolebinding:绑定到集群角色上
   如果使用clusterrolebinding绑定到clusterrole上,表示绑定的用户拥有所有namespace的权限


 Role 和 ClusterRole

Role普通角色:一个Role对象只能用于授予对某一单一命名空间中资源的访问权限,普通角色只是在当前的名称空间生效。简而言之,一个 Role 只可以用来对某一命名空间中的资源赋予访问权限。
 ClusterRole集群角色:整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现,可以访问整个集群资源。

1.创建用户

对于User账户,我们可以通过创建k8s集群时自带的证书对我们(admin)权限(几乎)手动管理master中的凭证文件,并且将每个凭证文件和一个字符串对应起来,只要用户请求中有信息(一般来自本地保存的.kube/config文件中)能够证明自己有任意一个凭证文件的授权,那么这个请求就被认为是一个合法用户发出的,同时,在证书中还可以加入用户所在的组(group)的信息,k8s可以据此认为user在一个组中或者后期通过rolebinding等赋予操作权限。

#创建私钥,生成一个 2048 位的 aren.key 文件
[root@kube-master rbac]# umask 077; openssl genrsa -out aren.key 2048
#用此私钥创建一个csr(证书签名请求)文件
[root@kube-master rbac]# openssl  req -new -key aren.key -out aren.csr -subj  "/CN=aren" #这个地方是用户名
#拿着私钥和请求文件生成证书
[root@kube-master rbac]# openssl x509 -req -in aren.csr -CA  /etc/kubernetes/pki/ca.crt  -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out aren.crt -days 365
Signature ok
subject=/CN=aren
Getting CA Private Key
#生成账号
[root@kube-master rbac]# kubectl config set-credentials aren --client-certificate=aren.crt --client-key=aren.key --embed-certs=true
User "aren" set.
#指的是创建这个账号的环境在当前名称空间中
[root@kube-master rbac]# kubectl config set-context aren@kubernetes --cluster=kubernetes --user=aren
Context "aren@kubernetes" modified.
#、切换用户
[root@kube-master rbac]# kubectl config use-context aren@kubernetes
Switched to context "aren@kubernetes".
#查看
[root@kube-master rbac]#  kubectl config current-context
aren@kubernetes

2.role和rolebinding

先切回管理账号

[root@kube-master rbac]# kubectl  config   use-context  kubernetes-admin@kubernetes
2.1创建一个角色(role)---设置权限

--verb: 相当于是权限
--resource:给什么资源使用

[root@kube-master rbac]# kubectl  create role role-reader  --verb=get,list,watch --resource=pod,svc
role.rbac.authorization.k8s.io/role-reader created

###########或者############

#yaml文件方式
[root@kube-master rbac]# vim role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: role-reader
rules: #定义规则
 - apiGroups: [""]  #表示当前pod使用核心的APIserver组,默认用""表示就可以
   resources: ["pods","svc"]
   verbs: ["get", "list", "watch", "create", "update", "delete"] #["*"]表示所有权限

#启动
# kubectl apply -f role.yaml

查看role

[root@kube-master rbac]# kubectl  get role
NAME          CREATED AT
role-reader   2023-12-16T08:54:10Z
2.2让用户aren,和role-reader角色绑定

arenrole-binding:绑定名

--role=arenrole-binding  指定角色

--user=aren  指定用户

[root@kube-master rbac]#  kubectl  create  rolebinding arenrole-binding  --role=role-reader  --user=aren
rolebinding.rbac.authorization.k8s.io/arenrole-binding created

##############或者##################
#yaml格式
[root@kube-master rbac]# vim role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: arenrole-binding
subjects:    #定义对那个主体进行操作,有三种Subjects:Service Account、User Account、Groups
- kind: User
  name: aren
  apiGroup: rbac.authorization.k8s.io
roleRef:  #定义使用哪个角色
  kind: Role
  name: role-reader
  apiGroup: rbac.authorization.k8s.io


#加载启动
# kubectl apply -f role-binding.yaml 

查看绑定

[root@kube-master rbac]# kubectl  get rolebinding
NAME               ROLE               AGE
arenrole-binding   Role/role-reader   4m1s
测试

切换用户无法使用授权以外的权限。

#切换用户
[root@kube-master rbac]# kubectl  config  use-context aren@kubernetes
Switched to context "aren@kubernetes".

#查看权限(只授权了default名称空间pod和svc的get,list,watch权限)
[root@kube-master rbac]# kubectl  get pod
NAME            READY   STATUS    RESTARTS     AGE
mysa-pod        1/1     Running   1 (8h ago)   24h
mysql           1/1     Running   1 (8h ago)   20h
nginx           1/1     Running   1 (8h ago)   19h
test-downward   1/1     Running   0            7h19m

 #无权限删除
[root@kube-master rbac]# kubectl  delete nginx
Error from server (Forbidden): pods "nginx" is forbidden: User "aren" cannot delete resource "pods" in API group "" in the namespace "default"

3.clusterrole和clusterrolebinding

删除aren账号之前绑定的rolebinding

[root@kube-master rbac]#  kubectl  delete rolebinding  arenrole-binding
rolebinding.rbac.authorization.k8s.io "arenrole-binding" deleted
3.1创建clusterrole #可以访问全部的namespace
[root@kube-master rbac]# kubectl create clusterrole myclusterrole --verb=get,list,watch --resource=pod,svc
clusterrole.rbac.authorization.k8s.io/myclusterrole created


##########或者#############
#yaml格式
[root@kube-master rbac]# vim clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: myclusterrole
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

#启动
kubectl apply -f clusterrole.yaml
#查看clusterrole
[root@kube-master rbac]# kubectl get clusterrole myclusterrole
NAME            CREATED AT
myclusterrole   2023-12-16T09:16:31Z
3.2绑定集群角色到aren上

clusterrolebinding  集群角色绑定名

-clusterrole=myclusterrole  指定集群角色

--user=aren   指定用户

[root@kube-master rbac]# kubectl  create clusterrolebinding arencluster-rolebinding   --clusterrole=myclusterrole --user=aren

##########或者############
yaml格式
[root@kub-k8s-master ~]# vim clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: arencluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: aren


#启动
kubectl  apply -f clusterrolebinding.yaml

#查看绑定
[root@kube-master rbac]# kubectl get clusterrolebinding arencluster-rolebinding
NAME                      ROLE                        AGE
arencluster-rolebinding   ClusterRole/myclusterrole   56s
测试

切换用户查看kube-system命名空间的pod(查看成功)

#切换账号
[root@kube-master rbac]# kubectl  config use-context aren@kubernetes
Switched to context "aren@kubernetes".

#查看权限 查看kube-system空间的pod
[root@kube-master rbac]# kubectl  get pod -n kube-system
NAME                                       READY   STATUS    RESTARTS        AGE
calico-kube-controllers-7c87c5f9b8-467xf   1/1     Running   20 (8h ago)     4d20h
calico-node-ql7kv                          1/1     Running   8 (8h ago)      4d22h
calico-node-rmnbh                          1/1     Running   10 (8h ago)     4d22h
calico-node-z22v9                          1/1     Running   15 (150m ago)   4d22h
coredns-78fcd69978-54v6q                   1/1     Running   8 (8h ago)      4d22h
coredns-78fcd69978-gt2rx                   1/1     Running   8 (8h ago)      4d22h
etcd-kube-master                           1/1     Running   10 (8h ago)     4d22h
kube-apiserver-kube-master                 1/1     Running   11 (8h ago)     4d22h
kube-controller-manager-kube-master        1/1     Running   21 (151m ago)   4d22h
kube-proxy-j97dk                           1/1     Running   8 (8h ago)      4d22h
kube-proxy-mmppf                           1/1     Running   11 (8h ago)     4d22h
kube-proxy-r8288                           1/1     Running   8 (8h ago)      4d22h
kube-scheduler-kube-master                 1/1     Running   15 (149m ago)   3d20h

设置上下文和账户切换

设置工作上下文

 kubectl config set-context aren@kubernetes --cluster=kubernetes --user=aren

查看工作上下文

kubectl  config  view

切换用户文章来源地址https://www.toymoban.com/news/detail-774663.html

 kubectl  config use-context  用户名@kubernetes

到了这里,关于K8s中Service Account和RBAC的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Spring Cloud Kubernetes】使用k8s原生service实现服务注册和发现

    @TOC 现在微服务开发模式应用的越来越广泛,注册中心 Eureka 也逐渐被其它注册中心产品替代,比如阿里出品的 Nacos 。随着云原生相关技术的普及, k8s 迅猛发展,我们把 K8s 中的 Pod 暴露给外部访问,通过少了 Service ,这也是今天的主角。 有没有发现,其实 Service 已经解决了

    2024年02月12日
    浏览(85)
  • 【Kubernetes】第二十二篇 - k8s 部署 MySQL 服务(secret、deployment、service)

    上一篇,介绍基于 k8s 项目部署流程设计; 本篇,介绍 MySQL 服务的部署; 部署 MySQL 可以为指定 node 添加污点,专门用于 mysql 部署(当前只有一个节点,不考虑); 为了保证mysql容器重启时数据不会丢失:创建 mysql 数据目录,用于存储 mysql 数据,实现 MySQL 数据的持久化;

    2024年02月03日
    浏览(60)
  • k8s - 安全认证(RBAC)

    api server 是集群访问控制的统一入口 k8s认证过程: 认证 - 授权 - 准入控制 ( adminationcontroller ) 1 认证()是对客户端的认证,简单说就是账户密码 2 授权()是资源的授权,容器、网络、存储资源的权限 3 准入机制 准入控制器位于api server ,在对象被持久化之前,准入控制器

    2024年02月08日
    浏览(41)
  • K8s RBAC认证授权深度解析

    ​ 🐇明明跟你说过:个人主页 🏅个人专栏:《Kubernetes航线图:从船长到K8s掌舵者》 🏅 🔖行路有良友,便是天堂🔖 目录 一、前言 1、k8s简介 2、RBAC简介  二、RBAC核心概念 1、角色(Role)与集群角色(ClusterRole) 2、角色绑定(RoleBinding)与集群角色绑定(ClusterRoleBindin

    2024年04月28日
    浏览(37)
  • 25-k8s集群中-RBAC用户角色资源权限

            我们通过k8s各组件架构,指导各个组件之间是使用https进行数据加密及交互的,那么同理,我们作为“使用”k8s的各种资源,也是通过https进行数据加密的;         k8s通过我们家目录下的证书来判断我们是谁?通过证书内容,认定我们的权限; 用户证书的位置 [r

    2024年02月22日
    浏览(47)
  • K8s攻击案例:RBAC配置不当导致集群接管

    01、概述 Service Account本质是服务账号,是Pod连接K8s集群的凭证。在默认情况下,系统会为创建的Pod提供一个默认的Service Account,用户也可以自定义Service Account,与Service Account关联的凭证会自动挂载到Pod的文件系统中。 当攻击者通过某个web应用获取到一个Pod权限时,如果RBAC权

    2024年02月02日
    浏览(46)
  • Kubernetes 启动Pod的方法-Pod的调度算法-Pod间的通信-k8s的控制器-Pod资源控制-发布Service服务

    目录 Pod 参考文档:Pod | Kubernetes Pod配置文件:simple-pod.yaml 对master进行如下操作 Pod的状态有: 参考文档:(70条消息) Pod生命周期中的状态解释_pod状态_闹玩儿扣眼珠子的博客-CSDN博客 进入Pod内的nginx容器: 当我们创建一个Pod,其中的步骤是什么?(启动Pob的流程) 大概步骤:

    2024年02月13日
    浏览(71)
  • (2022版)一套教程搞定k8s安装到实战 | RBAC

    视频来源:B站《(2022版)最新、最全、最详细的Kubernetes(K8s)教程,从K8s安装到实战一套搞定》 一边学习一边整理老师的课程内容及试验笔记,并与大家分享,侵权即删,谢谢支持! 附上汇总贴:(2022版)一套教程搞定k8s安装到实战 | 汇总_COCOgsta的博客-CSDN博客 基于角色

    2024年02月04日
    浏览(30)
  • 第22关 深入解析K8s中的RBAC角色访问控制策略

    ------ 课程视频同步分享在今日头条和B站 大家好,我是博哥爱运维,在k8s上我们如何控制访问权限呢,答案就是 Role-based access control ( RBAC ) - 基于角色(Role)的访问控制,(RBAC)是一种基于组织中用户的角色来调节控制对 计算机或网络资源的访问的方法。 在早期的K8s版本,

    2024年02月04日
    浏览(40)
  • K8s中的RBAC(Role-Based Access Control)

    RBAC(基于角色的访问控制)是一种在Kubernetes中用于控制用户对资源的访问权限的机制。以下是RBAC的设计实现说明: 角色(Role)和角色绑定(RoleBinding):角色定义了一组权限,角色绑定将角色与用户或用户组相关联。通过角色和角色绑定,可以在集群或命名空间级别授予用

    2024年02月09日
    浏览(29)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包