你有了解过Kubernetes的认证授权链路吗?是否对TKE的权限控制CAM策略、服务角色傻傻分不清楚?本文将会向你介绍腾讯云TKE平台侧的访问控制Kubernetes访问控制链路,以及演示如何将平台侧账号对接到Kubernetes内。

当你在使用腾讯云容器服务TKE(Tencent Kubernetes Engine)的时候,如果多人共用一个账号的情况下,是否有遇到以下问题呢?

  • 密钥由多人共享,泄密风险高。
  • 无法限制其他人的访问权限,其他人误操作易造成安全风险。

为了解决以上问题,腾讯云CAM(Cloud Access Management)提供了主账号和子账号的认证体系以及基于角色的权限控制。

而不同的子账号对于TKE平台侧资源的控制粒度比较粗(cluster实例级别),又会遇到以下问题:

  • 同一个集群由多子账号可访问,无法保证集群资源级别、命名空间级别的读写控制。
  • 集群的高权限子账户无法对低权限子账户进行授权管理。

为了解决以上两个问题,TKE针对平台侧资源Kubernetes资源分别进行相应的访问控制管理。

平台侧访问控制

首先介绍下什么是平台侧资源,平台侧资源即Cluster资源CVM资源CLB资源VPC资源等腾讯云资源,而访问的用户主要分为用户服务角色载体

  1. 用户就是我们平时登录控制台的主账号、子账号或者协作者账号
  2. 服务角色是一种定义好带有某些权限的角色,可以将这个角色赋予某个载体,可以是某个其他账户,也可以是腾讯云下一个产品的服务提供者,CAM会默认为产品提供一个预设的载体和默认的角色,例如TKE的默认角色就是TKE_QCSRole,而载体就是ccs.qcloud.com

而这个角色有什么用处呢?举个TKE的例子,比如TKE的service-controller会Watch集群内的Service资源,如果需要创建LoadBalance类型的Service,会通过云API购买并创建CLB资源,而service-controller是TKE平台为用户部署的,去访问云API需要有身份,这个身份就是ccs.qcloud.com载体,而权限则需要用户给载体授予一个角色,即TKE_QCSRole。只有用户在授权TKE载体之后,TKE才可以通过服务扮演的方式代替用户购买CLB。

下面我会简单为你介绍如何给用户授权,以及如何给TKE平台授予角色

定制策略

TKE通过接入CAM,对集群的API接口级别进行权限细分,需要您在CAM控制台对子账户进行不同的权限授予。同时TKE也在CAM侧提供了预设的权限,提供您默认选择,例如:

也可以自定义策略,具体策略定制请参考CAM产品介绍文档

例如拥有只读权限的子账户尝试修改集群名称,将会在API接口时校验CAM权限失败

划分用户组

可以依据团队的职责划分好用户组,将之前规划好的自定义策略绑定到一个用户组上,来方便的进行权限管理。

例如:有新同学入职时可方便的加入指定用户组(如运维组),就可以获取到该用户组的权限,避免了繁琐的权限配置操作。

授予TKE角色权限

使用TKE容器服务需要授予TKE平台为您操作CVM\CLB\VPC\CBS等权限,所以首次访问TKE控制台需要确保同意授权,即创建预设角色TKE_QCSRole,此角色默认授予TKE载体,该载体会通过CAM获取操作您集群的临时密钥,来进行相应的云API操作。

更多

更多丰富的平台侧访问控制用法请访问CAM产品说明文档

Kubernetes访问控制

介绍完平台侧资源的访问控制,我们再来看看TKE集群内的资源如何进行权限管理。当不同的子账户都拥有访问同一个TKE Kubernetes集群权限之后,如何保证不同的子账户,对于集群内资源拥有不同的角色和权限呢?让我们首先从社区的Kubernetes访问链路来分析整个过程,从而向您介绍TKE是如何实现容器服务子账户对接Kubernetes认证授权体系的。

Overview

首先从宏观的角度看下Kubernetes的请求链路是如何进行的。图片来源于k8s社区官网。

可以大概了解到一个请求的链路是依次通过Authentication(认证,简称Authn)、Authorization(授权,简称Authz)、AdmissionControl(准入控制),从而获取到后端持久化的数据。

从图中可以看到Authn、Authz、AdmissionControl是由多个模块组成的,每个步骤都有多种方式构成的。

在进入认证模块之前会将HTTP的Request进行构建context,而context中就包含了用户的RequestInfo,userInfo、Verb、APIGroup、Version、Namespace、Resource、Path等。

带着这些信息,下面我们来一次看下准入过程中的每个步骤吧。

Kubernetes认证

认证的过程的证明user身份的过程。

Kubernetes中有两类用户,一类是ServiceAccount,一类是集群真实的用户。

ServiceAccount账户是由Kubernetes提供API(资源)进行创建和管理的,ServiceAccount可以认为是特殊的Secret资源,可用户集群内资源访问APIServer的认证所用。通过可以通过mount的方式挂载到Pod内进行使用。

真实的用户通常是从外部发起请求访问APIServer,由管理员进行管理认证凭证,而Kubernetes本身不管理任何的用户和凭证信息的,即所有的用户都是逻辑上的用户,无法通过API调用Kubernetes API进行创建真实用户。

Kubernetes认证的方式众多,常见的有TLS客户端证书双向认证、BearerToken认证、BasicAuthorization或认证代理(WebHook)

所有的认证方式都是以插件的形式串联在认证链路中,只要有一种认证方式通过,即可通过认证模块,且后续的认证方式不会被执行。

在此处参考一点点Kubernetes APIServer Authentication模块的代码,可以发现,任何的认证方式都是一下Interface的实现方式都是接收http Request请求,然后会返回一个user.Info的结构体,一个bool,以及一个error

// Request attempts to extract authentication information from a request and returns
// information about the current user and true if successful, false if not successful,
// or an error if the request could not be checked.
type Request interface {
AuthenticateRequest(req *http.Request) (user.Info, bool, error)
}

user.Info中包含了用户的信息,包括UserName、UUID、Group、Extra。

bool返回了用户是否通过认证,false的话即返回无法通过认证,即返回401错误。

error则返回了当Request无法被检查的错误,如果遇到错误则会继续进行下一种注册的方式进行认证。

如果认证通过,则会把user.Info写入到到请求的context中,后续请求过程可以随时获取用户信息,比如授权时进行鉴权。

下面我会以Kubernetes代码中的认证方式顺序,挑选几项认证方式,并结合TKE开启的认证方式来向你介绍TKE创建的Kubernetes集群默认的认证策略。

Basic Authentication

APIServer启动参数--basic-auth-file=SOMEFILE指定basic认证的csv文件,在APIServer启动之后修改此文件都不会生效,需要重启APIServer来更新basic authentication的token。csv文件格式为:token,user,uid,"group1,group2,group3"

请求时,需要指定HTTP Header中Authentication为Basic,并跟上Base64Encode(user:passward)值。

x509客户端证书

APIServer启动参数--client-ca-file=SOMEFILE指定CA证书,而在TKE的K8s集群创建过程中,会对集群进行自签名CA密钥和证书用于管理,如果用户下发的客户端证书是由此CA证书的密钥签发的,那么就可以通过客户端证书认证,并使用客户端证书中的CommonName、Group字段分别作为Kubernetes的UserInfo中Username和Group信息。

目前TKE对接子账户都是通过自签名的CA凭证进行签发子账户Uin对应CN的客户端证书。

Bearer Token

Bearer Token的认证方式包含很多,比如启动参数指定的、ServiceAccount(也是一种特殊的BeaerToken)、BootstrapToken、OIDCIssure、WebhookToken

1. 默认指定Token csv文件

APIServer启动参数--token-auth-file=SOMEFILE指定Bearer Token认证的csv文件。和Basic Authentication方式相似,只不过请求APIServer时,指定的HTTP认证方式为Bearer方式。此Bearer后直接跟passward即可。csv文件格式为:password,user,uid,"group1,group2,group3"

请求时,需要指定HTTP Header中Authentication为Bearer,并跟上Base64Encode(user:passward)值。

2. ServiceAccount

ServiceAccount也是一种特殊beaer token,ServiceAccount在Kubernetes中是一种资源,创建一个ServiceAccount资源之后默认会创建一个Secret资源,而Secret资源中就包含了一个JWT格式的Token字段,以Bearer Token的方式请求到Kube-APIServer,Kube-APIServer解析token中的部分user信息,以及validate以下ServiceAccount是否存在即可进行认证检查。这种方式即之前提到的“两种用户”中常见的集群内认证方式,ServiceAccount,主要用于集群内资源访问APIServer,但不限于集群内。

3. BootstrapToken

此项开关在Kubernetes v1.18版本中才为stable版本,此类Token是专门用来引导集群安装使用的,需要配合controller-manager的TokenCleaner。

目前TKE默认开启此配置。

4. OpenID Connect Tokens

OIDCToken的认证方式是结合OAuth2向身份提供方获取ID Token来访问APIServer。

如需要开启此项功能,需要在APIServer的启动参数中指定oidc的配置参数,例如--oidc-issuer-url指定oidc身份提供方的地址,--oidc-client-id指定身份提供方侧的账户ID,--oidc-username-claim身份提供方的用户名。

具体可参考Kubernetes官方文档,目前公有云TKE没有使用此参数对接腾讯云账户,因为涉及用户需要主动登录授权后才可返回Id Token,和当前官网交互冲突,可以在后续CLI工具中实现。

5. Webhook Token Server

Webhook Token是一种hook的方式来校验是否认证通过。

APIServer启动参数--authentication-token-webhook-config-file--authentication-token-webhook-cache-ttl来分别指定Webhook地址以及token的cache ttl。

若APiServer开启此方式进行认证校验,则在接受到用户的Request之后,会包装Bearer Token成一个TokenReview发送给WebHookServer,Server端接收到之后会进行校验,并返回TokenReview接口,在status字段中进行反馈是否通过校验通过和user.Info信息。

总结

以上即为Kubernetes APIServer认证的几种方式,TKE在每种认证方式都有支持。供用户灵活使用。

目前TKE正在推使用x509客户端证书方式来进行认证管理,以方便进行对接子账户的创建、授权管理、更新。

Kubernetes授权

Kubernetes的授权模式支持一下几种,和认证一样,参考开始说的RequestInfo context,可知用户Reqeust的context除了认证需要的userInfo,还有一些其他的字段例如Verb、APIGroup、APIVersion、Resource、Namespaces、Path……

授权就是判断user是否拥有操作资源的相应权限。

Kubernetes支持AlwaysAllow、AlwaysDeny、Node、ABAC、RBAC、Webhook授权Mode,和认证一样,只要有一种鉴权模块通过,即可返回资源。

在这里重点介绍下面两种方式

RBAC

RBAC(Role-Based Access Control),Kubernetes提供ClusterRole、Role资源,分别对应集群维度、Namespace维度角色权限管控,用户可以自定义相应的ClusterRole、Role资源,绑定到已经认证的User之上。

如下tke:pod-reader ClusterRole,定义了该角色可以访问core apigroup下面对pods资源的get/watch/list操作

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: tke:pod-reader
rules:
- apiGroups: [""] # "" 指定核心 API 组
resources: ["pods"]
verbs: ["get", "watch", "list"] ---
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "alex" 能够读取 "default" 命名空间中的 Pods
kind: ClusterRoleBinding
metadata:
name: alex-ClusterRole
subjects:
- kind: User
name: alex
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: tke:pod-reader # 这里的名称必须与你想要绑定的 Role 或 ClusterRole 名称一致
apiGroup: rbac.authorization.k8s.io

通过以上的yaml配置,通过认证模块到达授权模块的requestInfo中userInfo信息是alex的请求,在授权模块中走到RBAC授权模块时,则会进行查询集群的ClusterRole/ClusterRoleBinding信息。进行判断是否拥有context相应操作的权限。

TKE的对接子账户的权限授权策略就是使用的Kubernetes原生的RBAC进行对子账户资源访问控制,这样符合原生,符合有K8s使用习惯的用户。

WebHook

Webhook模式是一种基于HTTP回调的方式,通过配置好授权webhook server地址。当APIServer接收到request的时候,会进行包装SubjectAccessReview请求Webhook Server,Webhook Server会进行判断是否可以访问,然后返回allow信息。

以下是kubernetes社区一个例子,以供参考。

{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "kittensandponies",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
},
"user": "alex",
"group": [
"group1",
"group2"
]
}
}
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": true
}
}

目前TKE没有考虑使用Webhook的模式,但是Webhook模式提供了强大的灵活性,比如对接CAM,实现K8s权限对接到平台侧,但是也有一定的风险和挑战,比如依赖CAM的稳定性;请求延迟、缓存/TTL的配置;CAM action配置与K8s权限对应关系。此项授权模式仍然在考虑中,有需求的用户可以反馈。

准入控制

什么是admission controller?

In a nutshell, Kubernetes admission controllers are plugins that govern and enforce how the cluster is used.

Admission controllers是K8s的插件,用来管理和强制用户如何来操作集群。

Admission controllers主要分为两个phase,一个是mutating,一个是validating。这两个阶段都是在authn&authz之后的,mutating做的变更准入,就是会对request的resource,进行转换,比如填充默认的requestLimit?而validating admission的意思就是验证准入,比如校验Pod副本数必须大于2。

API Server请求链路:

ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks, both of which are in beta status as of Kubernetes 1.13.

k8s支持30多种admission control 插件 ,而其中有两个具有强大的灵活性,即ValidatingAdmissionWebhooksMutatingAdmissionWebhooks,这两种控制变换和准入以Webhook的方式提供给用户使用,大大提高了灵活性,用户可以在集群创建自定义的AdmissionWebhookServer进行调整准入策略。

TKE中1.10及以上版本也默认开启了ValidatingAdmissionWebhooksMutatingAdmissionWebhooks

了解更多Admission Controller参考这里

kubernetes权限对接子账户

TKE权限实现对接子账户主要的方案是:x509客户端认证+Kubernetes RBAC授权

认证

每个子账户都拥有单独的属于自己的客户端证书,用于访问KubernetesAPIServer。

  • 用户在使用TKE的新授权模式时,不同子账户在获取集群访问凭证时,即前台访问集群详情页或调用DescribeClusterKubeconfig时,会展示子账户自己的x509客户端证书,此证书是每个集群的自签名CA签发的。
  • 该用户在控制台访问Kubernetes资源时,后台默认使用此子账户的客户端证书去访问用户Kubernetes APIServer。
  • 支持子账户更新自己的证书。
  • 支持主账户或集群tke:admin权限的账户进行查看更新其他子账户证书。

授权

TKE控制台通过Kubernetes原生的RBAC授权策略,对子账户提供细粒度的Kubernetes资源粒度权限控制。

  • 提供授权管理页,让主账号集群创建者默认拥有管理员权限,可以对其他拥有此集群DescribeCluster Action权限的子账户进行权限管理。

  • 并提供预设的ClusterRole。
    • 所有命名空间维度:

      • 管理员(tke:admin):对所有命名空间下资源的读写权限, 对集群节点,存储卷,命名空间,配额的读写权限, 可子账号和权限的读写权限
      • 运维人员(tke:ops):对所有命名空间下控制台可见资源的读写权限, 对集群节点,存储卷,命名空间,配额的读写权限
      • 开发人员(tke:dev):对所有命名空间下控制台可见资源的读写权限
      • 受限人员(tke:ro):对所有命名空间下控制台可见资源的只读权限
      • 用户自定义ClusterRole
    • 指定命名空间维度:
      • 开发人员(tke:ns:dev): 对所选命名空间下控制台可见资源的读写权限, 需要选择指定命名空间。
      • 只读用户(tke:ns:ro):对所选命名空间下控制台可见资源的只读权限, 需要选择指定命名空间。



  • 所有预设的ClusterRole都将带有固定label:cloud.tencent.com/tke-rbac-generated: "true"
  • 所有预设的ClusterRoleBinding都带有固定的annotations:cloud.tencent.com/tke-account-nickname: yournickname,及label:cloud.tencent.com/tke-account: "yourUIN"

更多

当然,除了TKE控制台提供的预设授权策略,管理员也可以通过kubectl操作ClusterRole/Role来实现自定义角色的灵活配置细粒度权限,以及操作ClusterRoleBinding/RoleBinding进行权限绑定,绑定到任意的角色权限之上。

例如你想设置CAM侧用户组为productA产品的pod-dev的用户权限只能够get/list/watch product-a命名空间下的pods资源,则你可以这样操作:

  • 创建自定义ClusterRole/Role:dev-pod-reader,yaml实例如下,文件名为developer.yaml

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole # 这里使用ClusterRole可以复用给产品其他命名空间
    metadata:
    name: pod-dev # pod-dev此角色为只能读取pod的开发
    rules:
    - apiGroups: [""] # "" 指定核心 API 组
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
  • 使用kubectl或者通过TKE控制台YAML创建资源创建上述Role

  • 绑定dev用户组下的dev1、dev2、dev3用户,绑定自定义权限pod-dev到product-a命名空间下

  • 从此dev1,dev2,dev3用户则只能使用get/list/watch访问product-a下的pods资源

    $ kubectl --kubeconfig=./dev.kubeconfig get pods
    Error from server (Forbidden): pods is forbidden: User "10000001xxxx-1592395536" cannot list resource "pods" in API group "" in the namespace "default"
    $ kubectl --kubeconfig=./dev.kubeconfig get pods -n product-a
    No resources found.

参考

  1. kubernetes认证介绍
  2. kubernetes授权介绍
  3. kubernetesRBAC介绍

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

一文读懂 TKE 及 Kubernetes 访问权限控制的更多相关文章

  1. kubernetes基础——一文读懂k8s

    容器 容器与虚拟机对比图(左边为容器.右边为虚拟机)   容器技术是虚拟化技术的一种,以Docker为例,Docker利用Linux的LXC(LinuX Containers)技术.CGroup(Co ...

  2. [转帖]一文读懂 HTTP/2

    一文读懂 HTTP/2 http://support.upyun.com/hc/kb/article/1048799/ 又小拍 • 发表于:2017年05月18日 15:34:45 • 更新于:201 ...

  3. 即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

    本文引用了“蔷薇Nina”的“Nginx 相关介绍(Nginx是什么?能干嘛?)”一文部分内容,感谢作者的无私分享. 1.引言   Nginx(及其衍生产品)是目前被大量使用的服务端反向代理和负载均衡 ...

  4. 【FIORI系列】SAP 一文读懂SAP Fiori是什么

    公众号:SAP Technical 本文作者:matinal 原文出处:http://www.cnblogs.com/SAPmatinal/ 原文链接:[FIORI系列]SAP 一文读懂SAP Fio ...

  5. 大数据篇:一文读懂@数据仓库(PPT文字版)

    大数据篇:一文读懂@数据仓库 1 网络词汇总结 1.1 数据中台 数据中台是聚合和治理跨域数据,将数据抽象封装成服务,提供给前台以业务价值的逻辑概念. 数据中台是一套可持续"让企业的数据用起 ...

  6. 一文读懂MySQL的事务隔离级别及MVCC机制

    回顾前文: 一文学会MySQL的explain工具 一文读懂MySQL的索引结构及查询优化 (同时再次强调,这几篇关于MySQL的探究都是基于5.7版本,相关总结与结论不一定适用于其他版本) 就软件开 ...

  7. 一文读懂HTTP/2及HTTP/3特性

    摘要: 学习 HTTP/2 与 HTTP/3. 前言 HTTP/2 相比于 HTTP/1,可以说是大幅度提高了网页的性能,只需要升级到该协议就可以减少很多之前需要做的性能优化工作,当然兼容问题以及如何 ...

  8. 一文读懂AI简史:当年各国烧钱许下的愿,有些至今仍未实现

    一文读懂AI简史:当年各国烧钱许下的愿,有些至今仍未实现 导读:近日,马云.马化腾.李彦宏等互联网大佬纷纷亮相2018世界人工智能大会,并登台演讲.关于人工智能的现状与未来,他们提出了各自的观点,也引 ...

  9. 一文读懂高性能网络编程中的I/O模型

    1.前言 随着互联网的发展,面对海量用户高并发业务,传统的阻塞式的服务端架构模式已经无能为力.本文(和下篇<高性能网络编程(六):一文读懂高性能网络编程中的线程模型>)旨在为大家提供有用的 ...

  10. 从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

    本文原作者阮一峰,作者博客:ruanyifeng.com. 1.引言 HTTP 协议是最重要的互联网基础协议之一,它从最初的仅为浏览网页的目的进化到现在,已经是短连接通信的事实工业标准,最新版本 HT ...

随机推荐

  1. ubuntu 配置VPN

    1.  sudo apt-get install pptpd 2.  修改/etc/pptpd.conf , vi /etc/pptpd.conf 找到#localip 192.168.0.1和#re ...

  2. Android常用Manager整理

    Android中常用Manager: ActivityManager,FragmentManager,PackagerManager, DownloadManager,ConnectivityMana ...

  3. VS2015 企业版不支持 JavaScript 语法高亮、智能提醒

    2015年7月,微软终于放出了 Visual Studio 2015 正式版,博主安装了 Visual Studio 2015 企业版之后,居然不支持 JavaScript 的语法高亮.智能提醒功能, ...

  4. [SDOI2013]费用流

    然而这是一道网络流... 如果满足Bob,使总费用最大: 设最大流的每条边流量(不是容量)为w[i],分配到每条边的费用为p[i],最大流量为wmax,p[i]的和为P 那么显然w[i] * p[i] ...

  5. EXCEL技能之数据去重

    本篇不属于技术类博文,只是想找个地方记录而已,既然是我的博客嘛,那就自己想写什么就写什么了. CRM中有个EXCEL数据导入功能,几千条数据导入CRM后去重,那是死的心都有的.往回想想EXCEL是否有 ...

  6. Http协议的理解

    作者技术有限,这篇博文都是结合网上的文章和自己的理解而写的,若存在错误,请无私指出,十分感谢! 协议,就是一种标准,即大家都要遵守的标准. 举个简单的例子:在中国,几乎人人都会讲普通话,不同地区的人有 ...

  7. 读《我是IT小小鸟》有感

    我是一只IT小小鸟,我与IT结缘.书中是作者对个人经历与经验在IT下的体会,却给了我们很好的借鉴. IT这门行业,不仅仅再局限于如我们高中老师教学所要求的内容.IT更加开放,可以通过GitHub.CS ...

  8. pytorch文档阅读(一)

    本章主要针对pytorch0.4.0英文文档的前两节,顺序可能有些不一样: torch torch.Tensor 张量 Tensors Data type CPU tensor GPU tensor ...

  9. C# 基础知识 (四).C#简单介绍及托管代码

            暑假转瞬即逝,从10天的支教生活到1周的江浙沪旅游,在这个漫长的暑假中我经历了非常多东西,也学到了非常多东西,也认识到了非常多不足之处!闲暇之余我准备又一次进一步巩固C#相关知识,包含 ...

  10. linux定时任务之crontab

    1.使用crontab crontab -u //设定某个用户的cron服务 crontab -l //列出某个用户cron服务的详细内容 crontab -r //删除某个用户的cron服务 cro ...