k8s--基础--23.3--认证-授权-准入控制--授权

最新推荐文章于 2024-09-16 13:14:39 发布
最新推荐文章于 2024-09-16 13:14:39 发布
阅读量685 收藏 2
点赞数
分类专栏： k8s 文章标签： kubernetes docker 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhou920786312/article/details/126242304
版权

k8s–基础–23.3–认证-授权-准入控制–授权

1、介绍

Kubernetes的授权是基于插件形式的，其常用的授权插件有以下几种
1. Node(节点认证)
2. ABAC(基于属性的访问控制)
3. RBAC(基于角色的访问控制)
4. Webhook(基于http回调机制的访问控制)

1.1、什么是RBAC(基于角色的访问控制)？

  1. 就是给用户(Users)授予一个角色(Role)，那么这个用户就有这个角色的权限。
  2. Role是有名称空间的限制的

在这里插入图片描述

1.1、RBAC工作逻辑

  1. 给用户(Users)授予一个角色(Role)，那么这个用户就有这个角色的权限。
  2. 授权方式有2种
    1. 名称空间级别 的授权
    2. 集群级别 的授权

1.1.1、名称空间级别 的授权

如果通过rolebinding绑定role，只能对rolebingding所在的名称空间的资源有权限,上图user1这个用户绑定到role1上，只对role1这个名称空间的资源有权限，对其他名称空间资源没有权限，这个属于名称空间级别的授权。

1.1.2、集群级别的授权机制

  1. 集群角色(ClusterRole)：可以认为是角色组的概念，就是一组角色
  2. 定义一个集群角色(ClusterRole)，对集群内的所有资源都有可操作的权限
    1. 将User2通过ClusterRoleBinding到ClusterRole，使User2拥有集群的操作权限
  3. 对资源的访问，没有名称空间的限制

1.2、Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图：

在这里插入图片描述

1.2.1、通过上图可以看到,3种绑定

  1. 用户通过 rolebinding绑定role
  2. 用户通过 clusterrolebinding绑定clusterrole
  3. 用户通过 rolebinding绑定clusterrole

1.4、ClusterRole的好处

  1. 假如有6个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义6个role和rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的role，这个是很麻烦的，所以我们引入clusterrole，定义一个clusterrole，对clusterrole授予所有权限，然后用户通过rolebinding绑定到clusterrole，就会拥有自己名称空间的管理员权限了，这样就减少了很多工作量。
  2. 注：RoleBinding仅仅对当前名称空间有对应的权限。

2、授权机制

  1. k8s中的授权策略也支持开启多个授权插件，只要一个验证通过即可。
  2. k8s授权处理主要是根据以下请求属性：
    1. user, group, extra
    2. API、请求方法(如get、post、update、patch和delete)和请求路径(如/api)
    3. 请求资源和子资源
    4. Namespace
    5. API Group
  3. k8s支持的授权模式
    1. Node Authorization
    2. ABAC Authorization
    3. RBAC Authorization
    4. Webhook Authorization

2.1、Node Authorization

通过配合NodeRestriction control准入控制插件来限制kubelet访问node，endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源。

2.1.1、配置方式

–authorization-mode=Node,RBAC –admission-control=…,NodeRestriction,…

2.2、ABAC Authorization

这种模式的实现相对比较生硬，就是在master node保存一份policy文件，指定不同用户(或用户组)对不同资源的访问权限,当修改该文件后，需要重启apiserver,跟openstack 的ABAC类似。policy文件的格式如下：


# Alice can do anything to all resources:
{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "alice",
        "namespace": "*",
        "resource": "*",
        "apiGroup": "*"
    }
}
# Kubelet can read any pods:
{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "kubelet",
        "namespace": "*",
        "resource": "pods",
        "readonly": true
    }
}

# Kubelet can read and write events:
{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "kubelet",
        "namespace": "*",
        "resource": "events"
    }
}

2.2.1、使用这种模式需要配置参数

–authorization-mode=ABAC –authorization-policy-file=SOME_FILENAME。

2.3、RBAC Authorization

  1. 通过启动参数使用RBAC：–authorization-mode=RBAC
  2. 使用kubeadm安装k8s默认会enabled。
  3. BAC API定义了四个资源对象用于描述RBAC中用户和资源之间的连接权限
    1. Role
    2. ClusterRole
    3. RoleBinding
    4. ClusterRoleBinding
  4. Role是定义在某个Namespace下的资源，在这个具体的Namespace下使用。
    1. ClusterRole与Role相似，只是ClusterRole是整个集群范围内使用的。
    2. RoleBinding把Role绑定到账户主体Subject，让Subject继承Role所在namespace下的权限。
    3. ClusterRoleBinding把ClusterRole绑定到Subject，让Subject集成ClusterRole在整个集群中的权限。
  5. API Server已经创建一系列ClusterRole和ClusterRoleBinding。
    1. 这些资源对象中名称以system:开头的，表示这个资源对象属于Kubernetes系统基础设施，也就说RBAC默认的集群角色已经完成足够的覆盖，让集群可以完全在 RBAC的管理下运行。
    2. 修改这些资源对象可能会引起未知的后果，例如
      1. 对于system:node这个ClusterRole定义了kubelet进程的权限，如果这个角色被修改，可能导致kubelet无法工作。

2.3.1、通过命令获取对应的Role相关资源进行增删改查

kubectl get roles --all-namespaces

kubectl get ClusterRoles

kubectl get rolebinding --all-namespaces

kubectl get clusterrolebinding

内容

[root@master1 test5]# kubectl get roles --all-namespaces
NAMESPACE              NAME                                             CREATED AT
kube-public            kubeadm:bootstrap-signer-clusterinfo             2022-03-19T02:06:49Z
kube-public            system:controller:bootstrap-signer               2022-03-19T02:06:47Z
kube-system            extension-apiserver-authentication-reader        2022-03-19T02:06:47Z
kube-system            kube-proxy                                       2022-03-19T02:06:49Z
kube-system            kubeadm:kubelet-config-1.18                      2022-03-19T02:06:47Z
kube-system            kubeadm:nodes-kubeadm-config                     2022-03-19T02:06:47Z
kube-system            system::leader-locking-kube-controller-manager   2022-03-19T02:06:47Z
kube-system            system::leader-locking-kube-scheduler            2022-03-19T02:06:47Z
kube-system            system:controller:bootstrap-signer               2022-03-19T02:06:47Z
kube-system            system:controller:cloud-provider                 2022-03-19T02:06:47Z
kube-system            system:controller:token-cleaner                  2022-03-19T02:06:47Z
kubernetes-dashboard   kubernetes-dashboard                             2022-03-19T13:40:13Z

2.4、Webhook Authorization

  1. 用户在外部提供 HTTPS 授权服务，然后配置 apiserver 调用该服务去进行授权。
  2. 参考官方文档
    1. https://kubernetes.io/docs/reference/access-authn-authz/webhook/

2.4.1、apiserver配置参数：

–authorization-webhook-config-file=SOME_FILENAME

3、kubernetes 中的认证机制

  1. kubernetes 支持多种认证机制，可以配置成多个认证体制共存，这样，只要有一个认证通过，这个request就认证通过了。下面介绍官网列举的几种常见认证机制
  2. 参考资料：https://kubernetes.io/docs/reference/access-authn-authz/authentication/

3.1、Service Account Tokens

  1. Service Account Token 是一种比较特殊的认证机制
  2. 适用于上文中提到的pod内部服务需要访问apiserver的认证情况
  3. 默认enabled。

3.1.1、启动参数文件

–service-account-key-file=/etc/kubernetes/pki/apiserver-key.pem
  1. 有启动参数文件，就使用启动参数文件
  2. 没有启动参数文件，默认使用–tls-private-key-file的值，即API Server的私钥。

3.1.2、验证

# 获取所有名称空间的sa账号
kubectl get serviceaccount --all-namespaces

在这里插入图片描述

可以看到k8s集群为所有的namespace创建了一个默认的service account，利用命令describe会发现service account只是关联了一个secret作为token，也就是service-account-token。


kubectl describe serviceaccount/default -n kube-system

在这里插入图片描述


kubectl get secret default-token-7xqxg -o yaml -n kube-system

在这里插入图片描述

可以看到service-account-token的secret资源包含的数据有三部分：

  1. ca.crt：

    1. API Server的CA公钥证书
    2. 用于Pod中的Process对API Server的服务端数字证书进行校验时使用的；

  2. namespace：

    1. Secret所在namespace的值的base64编码： echo -n “kube-system”|base64
    2. 在这里插入图片描述

  3. token：

    1. 该token就是由service-account-key-file的值签署(sign)生成。
    2. 这种认证方式主要由k8s集群自己管理，用户用到的情况比较少。
    3. 我们创建一个pod时，默认就会将该namespace对应的默认service account token mount到Pod中，所以无需我们操作便可以直接与apiserver通信

3.2、OpenID Connect Tokens

类似 OAuth2的认证方式，大致认证过程如下：

在这里插入图片描述

K8s（七）：部署、使用 metrics-server
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
04-02 2万+
🔴 K8s（七）：部署、使用 metrics-server
kubernetes安全机制
Drw_Dcm的博客
11-14 2642
kubernetes安全机制
K8S认证、授权与准入控制(RBAC)详解
weixin_33915554的博客
04-17 861
相关推荐 本文的kubernetes环境：https://blog.51cto.com/billy98/2350660 RBAC官方文档：https://kubernetes.io/docs/reference/access-authn-authz/rbac/ 前言 RBAC (Role-Based Access Control，基于角色的访问控制）是一种新型、灵活且使用广泛的访问控制机制，它...
k8s中的认证授权
最新发布
D2961953033的博客
09-16 1258
Authentication（认证）认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。Kubernetes集群有两类用户：由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts） 普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。Authorization（授权）
k8s安全管理：认证、授权、准入控制概述
weixin_51697758的博客
08-16 877
User Accounts（用户账户）和Service Accounts（服务账户）两种：UserAccount是给kubernetes集群外部用户使用的，例如运维或者集群管理人员，，kubeadm安装的k8s，默认用户账号是kubernetes-admin；APIServer需要对客户端做认证，使用kubeadm安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config这里面保存了客户端访问API Server的密钥相关信息。...
K8S-安全(认证、授权、准入控制)
迷雾总会解
08-26 1498
RoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。...
K8s存储------（五）访问控制（认证、授权(RBAC)、准入控制）
qq_41582883的博客
03-04 902
拉取私有仓库的镜像 （1）应用文件：kubectl apply -f pod3.yml apiVersion: v1 kind: Pod metadata: name: pod spec: containers: - name: redis-photo image: reg.westos.org/linux/redis-photon 查看pod的信息：kubectl get pod，私有仓库镜像拉取失败 查看pod的详细信息：kubectl describe pod p
k8s-ingress-claim:一种可以防止对HostsDomain进行意外重复声明的准入控制策略
05-02
k8s-ingress-claim提供了一种准入控制策略，可防止现有入口已经声明的入口意外重复请求主机/域。 执行 这被实现为 ，其中k8s-ingress-claim服务作为部署在每个集群上运行。 Webhook配置为将对ingress资源的CREATE和...
镜像 k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
04-22
k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2 被墙无法pull，使用nfs方式提供k8s PVC必须的镜像包。 本人小水管拉下来的，拿走不谢。 使用方法： #解压 tar -xvf k8s.gcr.io_sig-storage_nfs-...
k8s系列-04-k8s的认证、授权和准入控制
ouyangzhenxin的博客
03-08 751
声明：本文乃“运维家”原创，转载请注明出处，更多内容请关注公众号“运维家”。主旨本节主要介绍一下，k8s客户端如何经过认证访问到apiserver，以及k8s如何授权，是怎么判定访问者拥有什么权限等内容。认证1、客户端认证客户端认证也称为TLS双向认证，为什么这么说呢，是因为kubectl在访问apiserver的时候，apiserver也要认证kubectl是否正确，他们都会访问CA来进行验证，如下图：2、BearertokenBearertoken的方式，可以理解为apiserver将一个密码通过了非对
K8s第七篇授权认证
weixin_43803147的博客
01-02 8324
K8s授权认证： 认证检查：检查是否为合法的用户，支持多种认证插件，用户只要通过一种插件的认证，则为合法的用户。 授权检查：检查用户的权限。 准入控制：如果用户的操作关联到多个资源，则进行准入控制检查。 客户端可以通过API Server的URL对资源进行操作： user：username，uid。 group：组。 extra：额外信息。 API Request Path：K8s的API...
kubernetes集群的认证、授权、准入控制
weixin_30856965的博客
05-12 356
一、kubernetes集群安全架构 用户使用kubectl、客户机或通过REST请求访问API。可以授权用户和Kubernetes服务帐户进行API访问。当一个请求到达API时，它会经历几个阶段，如下图所示: 1.访问K8S集群的资源需要过三关：认证、鉴权、准入控制； 2.普通用户若要安全访问集群API Server，往往需要证书、Token或者用户名+密码； 3.Pod访问，...
K8s安全管理：认证、授权、准入控制
weixin_49888547的博客
06-07 4217
k8s 对我们整个系统的认证，授权，访问控制做了精密的设置；对于 k8s 集群来说，apiserver 是整个集群访问控制的唯一入口，我们在 k8s 集群之上部署应用程序的时候，也可以通过宿主机的NodePort 暴露的端口访问里面的程序，用户访问 kubernetes 集群需要经历如下认证过程：认证->授权->准入控制（adminationcontroller）1.认证(Authenticating)是对客户端的认证，通俗点就是用户名密码验证2.授权(Authorization)是对资源的授权，k8s 中
Kubernetes身份认证和授权操作全攻略：K8s 访问控制入门
Rancher
08-14 825
随着Kubernetes被广泛使用，成为业界公认的容器编排管理的标准框架，许多开发人员以及管理员对部署、弹性伸缩以及管理容器化应用程序等Kubernetes的关键概念都十分熟悉。而对于生产部署而言，Kubernetes的安全性至关重要。因此，了解平台如何管理用户和应用程序的身份认证和授权十分必要。 我们将推出一系列文章，以一种实践性的视角来了解平台内部的Kubernetes和Pod外部用户...
k8s--基础--23.4--认证-授权-准入控制--准入控制
zhou920786312的博客
08-15 402
Kubernetes的Admission Control实际上是一个准入控制器(Admission Controller)插件列表，发送到APIServer的请求都需要经过这个列表中的每个准入控制器插件的检查，如果某一个控制器插件准入失败，就准入失败。...
【kubernetes】通过外置CRI-DOCKER建立起新版K8s与Docker间的桥梁
cnskylee的博客
01-30 4704
kubernetes 从1.24版本开始，正式移除了内置的dockershim组件，这个组件是kubernetes官方开发和维护的一个容器运行时接口组件（即Container Runtime Interface），CRI的作用主要有两方便，一个是镜像的操作，如：下载、删除等，另一方面是对于容器的操作，包括容器的创建、停止和删除等。dockershim被移除后，意味着需要使用第三方的dockershim组件，如：cri-docker、containerd，才能继续在k8s集群中使用docker。
k8s认证和授权
qq_41009846的博客
09-01 1729
流程 Authentication:身份认证
k8s之RBAC 详解(基于角色的访问控制)
qfyangsheng的博客
08-19 1638
一个实验搞定RBAC RBAC基于角色的访问控制--全拼Role-Based Access Control ​ Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC来为Service Account鉴权 ​ 在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式。 ​ 在RABC API中，通过如下的步骤进行授权
K8S 安全认证机制（认证、授权（Role/ClusterRole/ClusterRole/ClusterRoleBinding）、准入控制）
weixin_45880055的博客
06-10 3036
文章目录一、访问控制概述二、认证管理三、授权管理Role、ClusterRoleRoleBinding、ClusterRoleBindingRoleBinding引用ClusterRole进行授权实例四、准入控制 一、访问控制概述 Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。 所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 客户端 在Kubernetes集群中，客户端通常有两类: User Account： 一般是独立于kubern
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值