k8s - 安全认证(RBAC)

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

简介

api server 是集群访问控制的统一入口

k8s认证过程: 认证 -> 授权 - > 准入控制 (adminationcontroller

1 认证()是对客户端的认证,简单说就是账户密码

2 授权()是资源的授权,容器、网络、存储资源的权限

3 准入机制

准入控制器位于api server ,在对象被持久化之前,准入控制器拦截对api server 的请求,一般用来做认证和授权。其中包括连个控制器:

MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。分别作为配置的变异和验
证准入控制 webhook。
变更(Mutating)准入控制:修改请求的对象
验证(Validating)准入控制:验证请求的对象

准入控制是api server 启动时参数配置。一个准入控制器可以属于以上两者中的一种,也可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制,然后再执行验证准入控 制。

我们在部署 Kubernetes 集群的时候都会默认开启一系列准入控制器,如果没有设置这些准入控制
器的话可以说你的 Kubernetes 集群就是在裸奔,应该只有集群管理员可以修改集群的准入控制
器。
例如我会默认开启如下的准入控制器。
--admission-
control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQ
uota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
k8s 的整体架构也是一个微服务的架构,所有的请求都是通过一个 GateWay,也就是 kube-apiserver 这个组件(对外提供 REST 服务),k8s 中客户端有两类,一种是普通用户,一种是集群 内的 Pod,这两种客户端的认证机制略有不同,但无论是哪一种,都需要依次经过认证,授权,准 入这三个机制。

1 认证

认证支持多种插件

1 令牌认证

客户端和服务端使用共享秘钥,认证信息经由http协议认证头部进行传递。

2 ssl 认证

通过ca签发的证书,完成客户端与服务端的认证

kubernetes 上的账号
ServiceAccount(服务账号)为pod调用api server 准备的账号
User account(用户账号)为用户调用api server 准备的
ServiceAccount
Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的。它 与 User account 不同,User account 是为人设计的,而 service account 则是为 Pod 中的进程 调用 Kubernetes API 而设计;User account 是跨 namespace 的,而 service account 则是仅 局限它所在的 namespace;每个 namespace 都会自动创建一个 default service account;
开启 ServiceAccount Admission Controller 后
1)每个 Pod 在创建后都会自动设置 spec.serviceAccount 为 default(除非指定了其他
ServiceAccout)
2)验证 Pod 引用的 service account 已经存在,否则拒绝创建;
当创建 pod 的时候,如果没有指定一个 serviceaccount,系统会自动在与该 pod 相同的
namespace 下为其指派一个 default service account。这是 pod 和 apiserver 之间进行通信的
账号,
查看默认空间下的pod
k8s - 安全认证(RBAC)
默认会挂载一个secret
k8s - 安全认证(RBAC)
挂载的这个secret ,是命名空间中默认存在的,通过这个secret可以和api server 连接认证,获取本命名空间中pod 等状态信息 k8s - 安全认证(RBAC)

 进入pod可以查看pod中的secret

k8s - 安全认证(RBAC)

 创建一个serviceaccount:

# 通过命令可以直接创建:
kubectl create serviceaccount 服务账户名称

通过查看sa详情,可以发现它属于default命名空间, 自动生成一个token
k8s - 安全认证(RBAC)

 k8s - 安全认证(RBAC)

k8s - 安全认证(RBAC)

这个 token 就是 sa 连接 apiserver 的认证信息,这个 token 也是登陆 k8s dashboard 的 token,这些是一个认证信息,能够登陆 k8s,能认证到 k8s,但是不能做别的事情,不代表权限,想要做其他事情,需要授权.

kubeconfig 文件

用户对资源访问需要通过apiserver进行通讯认证才能进行访问,此机制可以通过token,也可以通过配置文件

# 查看config文件
kubectl config view
# 展示信息
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    # apiserver 的地址
    server: https://192.168.241.191:6443
  # 集群的名字
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: default
    user: kubernetes-admin
  # 上下文的名字
  name: kubernetes-admin@kubernetes
# 当前上下文的名字
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

2 授权

如果用户通过认证,什么权限都没有,需要一些后续的授权操作,如对资源的增删该查等,
kubernetes1.6 之后开始有 RBAC(基于角色的访问控制机制)授权检查机制。
Kubernetes 的授权是基于插件形成的,其常用的授权插件有以下几种:
1)Node(节点认证)
2)ABAC(基于属性的访问控制)
3)RBAC(基于角色的访问控制)
4)Webhook(基于 http 回调机制的访问控制)
什么是 RBAC(基于角色的访问控制)?
让一个用户(Users)扮演一个角色(Role),角色拥有权限,从而让用户拥有这样的权限,随后在 授权机制当中,只需要将权限授予某个角色,此时用户将获取对应角色的权限,从而实现角色的访问 控制
在 k8s 的授权机制当中,采用 RBAC 的方式进行授权,其工作逻辑是,把对对象的操作权限定义到 一个角色当中,再将用户绑定到该角色,从而使用户得到对应角色的权限。如果通过 rolebinding 绑定 role,只能对 rolebingding 所在的名称空间的资源有权限。另外,k8s 为此还有一种集群级别的授权机制,就是定义一个集群角色(ClusterRole),对集群内 的所有资源都有可操作的权限,从而将 User2 通过 ClusterRoleBinding 到 ClusterRole,从而使 User2 拥有集群的操作权限。
上面我们说了两个角色绑定:
(1)用户通过 rolebinding 绑定 role
(2)用户通过 clusterrolebinding 绑定 clusterrole
还有一种:rolebinding 绑定 clusterrole
rolebinding 绑定 clusterrole 的好处:
假如有 n 个名称空间,每个名称空间的用户都需要对自己的名称空间有管理员权限,那么需要定义 n 个 role 和 rolebinding,然后依次绑定,如果名称空间更多,我们需要定义更多的 role,这个是很 麻烦的,所以我们引入 clusterrole,定义一个 clusterrole,对 clusterrole 授予所有权限,然后用 户通过 rolebinding 绑定到 clusterrole,就会拥有自己名称空间的管理员权限了
注:RoleBinding 仅仅对当前名称空间有对应的权限。

3 准入控制

准入控制只是用来定义我们授权检查完成之后的后续的其他安全检查操作的,进一步补充
了授权机制,由多个插件组合实行,一般而言在创建,删除,修改或者做代理时做补充;
Kubernetes 的 Admission Control 实际上是一个准入控制器(Admission Controller)插件列
表,发送到 APIServer 的请求都需要经过这个列表中的每个准入控制器插件的检查,如果某一个控 制器插件准入失败,就准入失败。
准入插件在api server 启动时进行配置。可以参考官网查看都有哪些准入插件。
使用准入控制器 | Kubernetes

RBAC 认证授权策略

RBAC 有四个资源对象,分别是 Role、ClusterRole、RoleBinding、ClusterRoleBinding
Role:角色
一组权限的集合,在一个命名空间中,可以用其来定义一个角色,只能对命名空间内的资源进行
授权。如果是集群级别的资源,则需要使用 ClusterRole。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role1
  # 指定所属名称空间
  namespace: dev
rules:
# 支持的 API 组列表,例如:"apiVersion: batch/v1"等
- apiGroups: [""]
#  资源类型
  resources: ["pods"]
# 具体资源名,空代表所有
  resourceNames: []
# 操作权限
  verbs: ["get","list","watch"]
ClusterRole:集群角色
具有和角色一致的命名空间资源的管理能力,还可用于以下特殊元素的授权
1、集群范围的资源,例如 Node
2、非资源型的路径,例如:/healthz
3、包含全部命名空间的资源,例如 Pods
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole1
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: []
  verbs: ["get","list","watch"]
RoleBinding:角色绑定、ClusterRolebinding:集群角 色绑定
角色绑定和集群角色绑定用于把一个角色绑定在一个目标上,可以是 User,Group,Service
Account,使用 RoleBinding 为某个命名空间授权,使用 ClusterRoleBinding 为集群范围内授
权。
# 将在dev 命名空间中把 role1 角色授予用户 test
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-binding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role1
subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io

k8s - 安全认证(RBAC)

绑定集群角色

# 通过绑定集群角色cluster-admin,对dev空间有完全权限
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: clusterrole-binding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: User
  name: all-test
  apiGroup: rbac.authorization.k8s.io

使用 RBAC 鉴权 | Kubernetes文章来源地址https://www.toymoban.com/news/detail-477321.html

限制不同的用户操作 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 "/CN=lucky"
# (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-certs=true
# (2)在 kubeconfig 下新增加一个 lucky 这个账号
kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
# (3)切换账号到 lucky,默认没有任何权限
kubectl config use-context lucky@kubernetes
# 通过这个命令切换回集群用户
kubectl config use-context kubernetes-admin@kubernetes
# 把 user 这个用户通过 rolebinding 绑定到 clusterrole 上,授予权限,权限只是在 lucky 这个名称空间有效
# (1)把 lucky 这个用户通过 rolebinding 绑定到 clusterrole 上
kubectl create ns lucky
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
# (2)切换到 lucky 这个用户
kubectl config use-context lucky@kubernetes
# (3)测试是否有权限 
kubectl get pods -n lucky 
# 有权限操作这个lucky名称空间 没有权限操作其他名称空间
kubectl get pods 
# 添加一个 lucky 的普通用户
useradd lucky 
# 要删除config文件中kubernetes-admin@kubernetes的信息,不然还可以通过切换用户使用admin用户
cp -ar /root/.kube/ /home/lucky/ 
chown -R lucky.lucky /home/lucky/ 
su - lucky 
kubectl get pods -n lucky

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

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

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

相关文章

  • Kubernetes技术--k8s核心技术集群的安全机制RBAC

    1.引入 我们在访问k8s的集群的时候,需要经过一下几个步骤: -a: 认证    -1 ). 传输安全:对外是不暴露端口:8080,只能够在内部访问,对外使用的是6443端口。    -2). 客户端认证的常用几种方式: -https 证书 基于ca证书 -https token 认证 通过token识别用户 -https

    2024年02月10日
    浏览(42)
  • 学习笔记三十一:k8s安全管理:认证、授权、准入控制概述SA介绍

    认证基本介绍:kubernetes主要通过APIserver对外提供服务,那么就需要对访问apiserver的用户做认证,如果任何人都能访问apiserver,那么就可以随意在k8s集群部署资源,这是非常危险的,也容易被黑客攻击渗透,所以需要我们对访问k8s系统的apiserver的用户进行认证,确保是合法的符

    2024年02月06日
    浏览(39)
  • 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运维篇】RBAC之创建集群用户管理K8S

    需求:公司新入职两位运维同事,分别是zhangsan、lisi,刚入职肯定不能给K8S管理员权限,所以需要创建两个系统账号,分别对应不同的权限: zhangsan用户 :对uat名称空间拥有管理员权限 lisi用户 :对所有命名空间拥有查看Pod的权限 第一步:生成一个私钥 第二步:生成一个证

    2024年02月16日
    浏览(51)
  • 最强的单点登录认证系统,基于RBAC统一权限控制,实现用户生命周期管理,开源、安全

    MaxKey 单点登录认证系统,谐音马克思的钥匙寓意是最大钥匙,是 业界领先的IAM-IDaas身份管理和认证产品 ,支持OAuth 2.x/OpenID Connect、SAML 2.0、JWT、CAS、SCIM等标准协议,提供 安全、标准和开放 的用户身份管理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC权限管理和资源管理等。 MaxKey注

    2024年02月03日
    浏览(57)
  • k8s简介及虚拟机快速搭建k8s集群

    1.1、部署方式的变迁 传统部署时代: 在物理服务器上运行应用程序 无法为应用程序定义资源边界 导致资源分配问题 例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况, 结果可能导致其他应用程序的性能下降。 一种解决方案是

    2024年02月12日
    浏览(79)
  • k8s简介、虚拟机快速搭建k8s集群、集群管理方式及K8S工作原理和组件介绍

    1.1、部署方式的变迁 传统部署时代: 在物理服务器上运行应用程序 无法为应用程序定义资源边界 导致资源分配问题 例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况, 结果可能导致其他应用程序的性能下降。 一种解决方案是

    2024年02月12日
    浏览(80)
  • 【云原生-K8s-1】kubeadm搭建k8s集群(一主两从)完整教程及kubernetes简介

    🍁 博主简介   🏅云计算领域优质创作者   🏅华为云开发者社区专家博主   🏅阿里云开发者社区专家博主 💊 交流社区: 运维交流社区 欢迎大家的加入!   Kubernetes(简称:k8s) 是Google在2014年6月开源的一个容器集群管理系统,使用Go语言开发,用于管理云平台中多

    2024年02月07日
    浏览(66)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包