kubernetes——RBAC鉴权

最新推荐文章于 2024-08-19 10:52:05 发布
最新推荐文章于 2024-08-19 10:52:05 发布
阅读量213 收藏
点赞数
文章标签： kubernetes 容器 云原生
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhouxin1111112/article/details/132670500
版权

简介

基于角色的访问控制(RBAC)是一种基于组织中各个用户的角色来调节对计算机或网络资源的访问的方法。

目的：防止k8s里的pod（会运行程序）能随意获取整个集群里的信息和访问集群里的资源

概念

  • Rule：规则，一组属于不同 API Group 的操作集合；
  • Role：角色，用于定义一组对 Kubernetes API 对象操作的一组规则，范围限定在 namespace；
  • ClusterRole：集群角色，该角色不受 namespace 的限制；
  • Subject：对象，也就是规则作用的对象；
  • RoleBinding：将角色和对象进行绑定，范围限定在 namespace；
  • ClusterRoleBinding：将集群角色和对象进行绑定，不受 namespace 限制
  • Serviceaccount： 服务账户--》pod--》apiserver
     

UserAccount和ServiceAccount介绍

架构图 

实验步骤（serviceaccoount使用案例介绍）

1.创建sa并绑定到pod

[root@k8smaster ingress]# kubectl create sa sa-lay
serviceaccount/sa-lay created
[root@k8smaster ~]# kubectl get sa
NAME      SECRETS   AGE
default   1         103d
sa-lay    1         2d3h

2.创建pod

[root@k8smaster sa]# cat sa-pod.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: sa-lay
  namespace: default
  labels:
    app: sa-lay
spec:
  serviceAccountName: sa-lay
  containers:
  - name: sa-nginx
    ports:
    - containerPort: 80
    image: nginx
    imagePullPolicy: IfNotPresent
    
[root@k8smaster sa]# kubectl apply -f sa-pod.yaml 
pod/sa-lay created

3.验证（拒绝访问）

访问apiserver，没权限

sa能通过https方式成功认证API，但是没有权限访问k8s资源，所以code状态码是403，表示没有权限操作k8s资源

[root@k8smaster sa]# kubectl exec -it sa-lay -- bash
#因为pod 会去访问k8s集群的apiserver，所以需要进入到pod里
root@sa-lay:/# cd /var/run/secrets/kubernetes.io/serviceaccount
root@sa-lay:/var/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt	namespace  token
#执行下面的命令去访问我们的apiserver 
root@sa-lay:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes/api/v1/namespaces/kube-system
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "namespaces \"kube-system\" is forbidden: User \"system:serviceaccount:default:sa-lay\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"kube-system\"",
  "reason": "Forbidden",
  "details": {
    "name": "kube-system",
    "kind": "namespaces"
  },
  "code": 403

4.对sa做授权

cluster-admin   这是一个权力非常大的clusterrole 集群角色
这个角色是k8s系统内部就有的，这是一个内置的集群角色 

[root@k8smaster sa]# kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin --serviceaccount=default:sa-lay
将default命名空间里的sa-lay服务账号绑定到 集群角色 cluster-admin 上
clusterrolebinding.rbac.authorization.k8s.io/sa-test-admin created
[root@k8smaster sa]# kubectl get clusterrolebinding  #查看有哪些服务账号进行了集群角色绑定
NAME                                                   ROLE                                                                               AGE
calico-kube-controllers                                ClusterRole/calico-kube-controllers                                                11d
calico-node                                            ClusterRole/calico-node                                                            11d
cluster-admin                                          ClusterRole/cluster-admin                                                          11d
ingress-nginx                                          ClusterRole/ingress-nginx                                                          99m
ingress-nginx-admission                                ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   11d
kubeadm:node-proxier                                   ClusterRole/system:node-proxier                                                    11d
metrics-server:system:auth-delegator                   ClusterRole/system:auth-delegator                                                  8d
sa-test-gaoshuo                                        ClusterRole/cluster-admin                                                          16s
system:basic-user                                      ClusterRole/system:basic-user                                                      11d
system:controller:attachdetach-controller              ClusterRole/system:controller:attachdetach-controller                              11d
system:controller:certificate-controller               ClusterRole/
[root@k8smaster sa]#

 

5.再次请求验证

再次请求，使用绑定好的集群角色 

[root@k8smaster sa]# kubectl exec -it sa-lay -- bash
root@sa-lay:/# cd /var/run/secrets/kubernetes.io/serviceaccount
root@sa-lay:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes/api/v1/namespaces/kube-system
{
  "kind": "Namespace",
  "apiVersion": "v1",
  "metadata": {
    "name": "kube-system",
    "uid": "1afd57db-8217-4eab-9015-42629f340013",
    "resourceVersion": "17",
    "creationTimestamp": "2023-05-15T12:19:01Z",
    "managedFields": [
      {
        "manager": "kube-apiserver",
        "operation": "Update",
        "apiVersion": "v1",
        "time": "2023-05-15T12:19:01Z",
        "fieldsType": "FieldsV1",
        "fieldsV1": {"f:status":{"f:phase":{}}}
      }
    ]
  },
  "spec": {
    "finalizers": [
      "kubernetes"
    ]
  },
  "status": {
    "phase": "Active"
  }

自定义角色

[root@k8smaster sa]# kubectl get clusterroles
NAME                                                                   CREATED AT
admin                                                                  2023-03-23T09:58:17Z
calico-kube-controllers                                                2023-03-23T10:02:38Z
calico-node                                                            2023-03-23T10:02:38Z
cluster-admin                                                          2023-03-23T09:58:17Z
[root@k8smaster sa]# kubectl describe  clusterroles cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

Resources  代表这个角色可以访问的资源  *.* 代表任意命名空间里的任意资源

Verbs ： 可以采取的动作 ：  get  list  watch

1.创建角色，控制权限 

[root@k8smaster sa]# cat role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
[root@k8smaster sa]# kubectl apply -f role.yaml 
role.rbac.authorization.k8s.io/pod-reader created

2.角色绑定

 sa绑定role

[root@k8smaster sa]# kubectl create rolebinding sa-test-lay --role=pod-reader --serviceaccount=default:sa-lay
rolebinding.rbac.authorization.k8s.io/sa-test-lay created

查看已经绑定的rolebinding 

[root@k8smaster sa]# kubectl get rolebinding
NAME          ROLE              AGE
sa-test-lay   Role/pod-reader   38s

3. 创建一个clusterrole

[root@k8smaster sa]# vim clusterrole.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: secret-reader
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
[root@k8smaster sa]# kubectl apply -f clusterrole.yaml 
clusterrole.rbac.authorization.k8s.io/secret-reader created
[root@k8smaster sa]# 
[root@k8smaster sa]# kubectl get clusterrole
secret-reader                                                          2023-04-04T08:51:10Z

4. 将sa-lay 绑定到secret-reader 的集群角色上

[root@k8smaster sa]# kubectl create clusterrolebinding sa-test-lay-2  --clusterrole=secret-reader  --serviceaccount=default:sa-lay
clusterrolebinding.rbac.authorization.k8s.io/sa-test-lay-2 created
[root@k8smaster sa]#
[root@k8smaster sa]# kubectl get clusterrolebinding
NAME                                                   ROLE                                                                               AGE
calico-kube-controllers                                ClusterRole/calico-kube-controllers    
sa-test-lay                                       ClusterRole/cluster-admin                                                          26m
sa-test-lay-2                                      ClusterRole/secret-reader                                                          38s

5. 验证：

启动就是进入sa-lay启动的pod，去访问apiserver里的pod资源和secret资源

[root@k8smaster sa]# kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
dapi-test-pod                      0/1     Error     0          4d23h
mypod                              1/1     Running   2          30h
nginx-configmap-test               1/1     Running   3          3d23h
sa-lay                             1/1     Running   0          43m
[root@k8smaster sa]# kubectl exec -it sa-lay  -- bash
root@sa-gaoshuo:/# 
root@sa-gaoshuo:~# cd /var/run/secrets/kubernetes.io/serviceaccount/
root@sa-gaoshuo:/var/run/secrets/kubernetes.io/serviceaccount# 
root@sa-gaoshuo:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)"  https://kubernetes/api/v1/pods  
root@sa-gaoshuo:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat .token)"  https://kubernetes/api/v1/secrets

宛如清风03
关注
从系统架构到服务网格——Service Mesh 实践与架构解析
AI天才研究院
08-30 619
随着云计算、容器技术、微服务架构的兴起，传统的单体应用逐渐被拆分为许多小而自治的服务。这些服务之间需要通信、协作，而这些交互模式也逐渐演变成了“面向服务架构”（SOA）中的一些最佳实践。但是在真实的业务场景中，服务之间的调用往往存在不确定性、复杂性、不可靠性等问题，这些问题很难通过修改服务端的代码来解决。因此，如何在服务间实现流量管理、熔断降级、请求路由、负载均衡等功能，成为当下企业的一个重点问题。
Kubernetes学习之RBAC
Micky_Yang的博客
09-17 330
一、访问控制概述 　　API Server作为Kubernetes集群系统的网关，是访问及管理资源对象的唯一入口，余下所有需要访问集群资源的组件，包括kube-controller-manager、kube-scheduler、kubelet和kube-proxy等集群基础组件、CoreDNS等集群的附加组件以及此前使用的kubelet命令等都要经由网关进行集群访问和管理。这些客户端均要经由API Server访问或改变集群状态并完成数据存储，并由它对每一次的访问请求进行合法性校验，包括用户身份鉴别、操作权
Kubectl之RBAC分析（含自定义Kubectl权限）
jiayu的博客
10-13 735
Kubectl之RBAC分析 实验环境 具体环境请参考我之前搭建k8s环境的博客：https://editor.csdn.net/md/?articleId=120629783 Kubectl搭建 # 创建kubectl证书请求文件 cat > admin-csr.json <<EOF { "CN": "admin", "hosts": [], "key": { "algo": "rsa", "size": 2048 }, "names": [
【云原生】RBAC授权详解
最新发布
weixin_73059729的博客
08-19 1175
基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC签权机制使用API（Kubernetes API中的一组相关路径）组来驱动签权决定，允许你通过Kubernetes API动态配置策略。
【kubernetes系列】Kubernetes之RBAC
margu_168的博客
07-11 1292
k8s的权限控制在实际工作中不那么经常使用，但是却是很重要的，我们需要深入理解才能很好的解决某些问题。在我们现目前的了解中，常用的授权插件有以下几种： Node（节点认证） ABAC(基于属性的访问控制) RBAC（基于角色的访问控制） Webhook（基于http回调机制的访问控制）kubernetes 集群相关所有的交互都需要通过apiserver来完成，对于这样集中式管理的系统来说，权限管理尤其重要，Kubernetes的授权是基于插件形式的，在1.5版的时候引入了基于角色的访问控制（Role-Bas
【云原生 | Kubernetes 系列】RBAC 鉴权
Q先生
08-20 737
基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC 鉴权机制使用来驱动鉴权决定， 允许你通过 Kubernetes API 动态配置策略。要启用 RBAC，在启动时将参数设置为一个逗号分隔的列表并确保其中包含RBAC。
【Kubernetes运维篇】RBAC认证授权详解(一)
热门推荐
秦子腾
07-08 1万+
RBAC是一种基于角色访问控制方式，它将权限和角色相关联，用户加入到角色中，就会拥有角色中的权限，RBAC的核心思想是，将权限赋予给角色，角色中加入多个用户，加入进来的用户会具有角色的权限，如果修改权限也是针对角色进行操作，而不是针对每个用户进行权限操作，这样效率太低了。官方中文参考文档在K8S中准入控制器的模块有很多，其中比较常用的有LimitRanger、ResourceQuota、ServiceAccount，也是K8S默认启用的准入模块(具体看K8S版本)，我们只需要定义对应的规则即可。
k8s——鉴权(Authorization)
benziwu的博客
12-27 643
RoloBinding 可以将角色中定义的权限授予用户或用户组，RoleBinding 包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users, groups, or service accounts)；在 RBAC API 中，Role 表示一组规则权限，权限只会增加(累加权限)，不存在一个资源一开始就有很多权限而通过RBAC 对其进行减少的操作；如果要在 RBAC 授权模型中控制这些子资源的访问权限，可以通过 / 分隔符来实现，以下是一个定义 pods 资资源。
kubernetes存储（四）——访问控制
weixin_56993834的博客
08-03 541
一 Kubernetes API 访问控制 用户使用 kubectl、客户端库或构造 REST 请求来访问 Kubernetes API。 人类用户和 Kubernetes 服务账户都可以被鉴权访问 API。 当请求到达 API 时，它会经历多个阶段，如下图所示： 二 认证 如上图步骤 1 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。 集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。 身份认证组件在认证节中有更详细的描述。
Kubernetes权限管理详解
zou8944的博客
12-03 1892
前面介绍过Kubernetes的结构组成，其中API Server用于与外界的交互，我们常用的命令行工具kubectl、UI工具lens、云服务商提供的WebUI，最终都是通过Restfule API的形式，走HTTP协议，到达API Server。此时就带来权限控制问题。 如上图，对来自外部的请求，Api Server会经过三个组件 Authentication：认证，验证用户的合法性，并从中提取出用户信息，如用户名、组等 Authorization：鉴权，鉴定该用户是否有权限访问指定资源 Admis
一文快速了解Docker和Kubernetes
j简说Linux的博客
11-14 944
Docker 是一个开源的应用容器引擎，是一种资源虚拟化技术，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上。虚拟化技术演历路径可分为三个时代：在没有 Docker 的时代，我们会使用硬件虚拟化（虚拟机）以提供隔离。这里，虚拟机通过在操作系统上建立了一个中间虚拟软件层 Hypervisor ，并利用物理机器的资源虚拟出多个虚拟硬件环境来共享宿主机的资源，其中的应用运行在虚拟机内核上。但是，虚拟机对硬件的利用率存在瓶颈，因为虚拟机很难根据当前业务量动态调整其
kubernetes-RBAC 鉴权
investor_的博客
03-21 1006
鉴权：鉴别权限 --》识别出某个主体（用户、组、服务账户）具有什么权限 ---》鉴定
【RBAC鉴权】node-casbin基础教程
IT飞牛
05-02 1217
RBAC鉴权，完整的英文描述是：Role-Based Access Control，中文意思是：基于角色（Role）的访问控制。这是一种广泛应用于计算机系统和网络安全领域的访问控制模型。简单来说，就是通过将权限分配给➡角色，再将角色分配给➡用户，来实现对系统资源的访问控制。一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。
如何使用RBAC进行鉴权
weixin_45578634的博客
12-20 504
如何使用RBAC进行鉴权
RBAC鉴权实验操作
yuer1228的博客
08-27 235
kind: Rolemetadata:rules:- apiGroups: [""] # "" 标明 core API 组以上就是使用RBAC将角色和对应的权限绑定的实验操作。
访问控制权限——RBAC技术文档
qq_45674716的博客
03-22 1608
权限管理功能是信息管理系统不可或缺的重要组成部分，是保证信息系统安全性的前提和基础。权限管理可以对用户的登录进行验证，对系统的资源访问进行鉴权，防止用户对系统越权使用，保障数据在采集、存储和传输过程中的安全性。RBAC基于角色的权限访问控制(Role-Based Access Control) 是商业系统中最常见的权限管理技术之一。RBAC是一种思想，任何编程语言都可以实现，其成熟简单的控制思想越来越受广大开发人员喜欢。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
RBAC 授权（前世今生）
weixin_44772835的博客
01-05 223
RBAC 授权（前世今生）
RBAC简介（*）
weixin_42408447的博客
11-05 8118
一.RBAC是什么 1.RBAC模型概述 RBAC是Role Based Access Control的英文缩写，意思是基于角色访问控制。 RBAC实际上就是针对产品去发掘需求时所用到的Who（角色）、What（拥有什么资源）、How（有哪些操作）的方式。 在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的操作。 RBAC主要包含四个子模型：RBAC0、RBAC1、RBAC2和RBAC3，整体又叫做RBAC96。 RBAC0 RBAC0是RBAC96模型家
fastapi怎么生成rbac鉴权系统
05-24
FastAPI本身不提供RBAC鉴权系统，但是可以通过第三方库来实现。这里介绍一种使用FastAPI和Pydantic实现RBAC鉴权系统的方法。 首先，需要定义用户模型和角色模型： ```python from typing import List from pydantic import BaseModel class User(BaseModel): id: int username: str password: str role_ids: List[int] = [] class Role(BaseModel): id: int name: str permissions: List[str] = [] ``` 然后，需要定义一个获取当前用户的函数，可以使用FastAPI的依赖注入功能实现： ```python from fastapi import Depends, HTTPException, status from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials from jwt import decode, exceptions from datetime import datetime, timedelta security = HTTPBearer() def get_current_user(credentials: HTTPAuthorizationCredentials = Depends(security)) -> User: token = credentials.credentials try: payload = decode(token, "SECRET_KEY", algorithms=["HS256"]) username = payload.get("sub") if username is None: raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid authentication credentials") user = get_user_by_username(username) if user is None: raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid username") return user except exceptions.DecodeError as e: raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid authentication credentials") except exceptions.ExpiredSignatureError as e: raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Token has expired") ``` 这个函数会从HTTP请求头中获取JWT令牌，并验证令牌的有效性和过期时间。如果验证通过，则返回当前用户对象。需要注意的是，这里的"SECRET_KEY"应该替换成真正的密钥。 接下来，需要定义一个检查权限的函数： ```python def check_permission(user: User, permission: str) -> bool: roles = get_roles_by_ids(user.role_ids) for role in roles: if permission in role.permissions: return True return False ``` 这个函数会检查当前用户是否拥有某个权限。需要根据用户的角色列表获取角色对象，然后检查角色是否拥有该权限。 最后，需要在路由定义中使用这些函数来进行鉴权： ```python from fastapi import FastAPI, Depends, HTTPException, status app = FastAPI() @app.get("/protected") def protected(user: User = Depends(get_current_user)): if not check_permission(user, "read_protected_data"): raise HTTPException(status_code=status.HTTP_403_FORBIDDEN, detail="You don't have permission to access this resource") return {"data": "This is protected data."} ``` 这个路由定义会使用get_current_user函数获取当前用户对象，然后使用check_permission函数检查是否拥有"read_protected_data"权限。如果没有权限，则返回HTTP 403 Forbidden错误。 需要注意的是，这里只是一个简单的示例，实际的RBAC鉴权系统可能会更加复杂。还需要考虑如何管理用户、角色和权限的数据，以及如何将鉴权逻辑集成到具体的业务逻辑中。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值