- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

华为云云原生钻石集训营第十课：Kubernetes安全权限管理深度剖析

菜鸟级攻城狮发表于 2021/08/04 21:50:05 2021/08/04

【摘要】华为云云原生钻石集训营第十课：Kubernetes安全权限管理深度剖析

课程目标：

学完本课程后，您将能够:

1.集群准入控制机制详解

2.集群认证机制剖析

3.集群鉴权机制RBAC剖析

1.集群准入控制机制详解

2.集群认证机制剖析

3.集群鉴权机制RBAC剖析

本节课，我们即将详细讲解kubernetes认证鉴权机制，让大家对k8s的认证和鉴权模块有一定的了解，其中包括kubernetes准入控制及RBAC的集群认证与鉴权机制

Kubernetes自身并没有用户管理能力，无法像操作Pod一样，通过API的方式创建/删除一个用户实例，也无法在etcd中找到用户对应的存储对象。

在Kubernetes的访问控制流程中，用户模型是通过请求方的访问控制凭证（如kubectI使用的kube-config中的证书、Pod中引入的ServerAccount)产生

集群准入控制机制详解

安全全景图

部署态的安全控制

认证，鉴权，Admission(准入控制)，Pod SecurityContext

运行态的安全控制

Network policy

本次课程主要讲解认证和鉴权模块

Kubernetes API访问控制

认证

集群创建脚本或者集群管理员配置API服务器，使之运行一个或多个身份认证组件。认证步骤输入整个HTTP请求，主要检查头部或客户端证书。

认证模块包含客户端证书、密码、普通令牌、引导令牌和JSON Web令牌(JWT，用于服务账户)，APl server依次尝试每个验证模块，直到其中一个成功.如果请求认证不通过，服务器将以HTTP状态码401拒绝该请求。

鉴权

认证通过后，可以识别具体客户信息，并根据用户和请求信息进行鉴权。kubernetes鉴权要求使用公共REST属性与现有的组织范围或云提供商范围的访问控制系统进行交互。请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。

Kubernetes API访问控制

请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。

Kubernetes支持多种鉴权模块，例如ABAC模式、RBAC模式和Webhook模式等。管理员创建集群时，他们配置应在API服务器中使用的鉴权模块。

Kubernetes API访问控制

Addmison controller

Admission Controller实现了对于Kubernetes集群的准入控制。如下图所示，Admission Controller以插件的形式内置于Kuberntes APIServer，在APIServer对请求的处理链路中发挥作用。

一般RESTful请求进入APIServer之后，会经过认证、审计、流量控制、鉴权等一系列通用处理，接着AdmissionController会对请求进行准入控制，主要包含Mutating和Validation两类操作，具体的操作都由相应的插件完成。

Mutating可以对请求中的资源对象进行修改而Validation则仅进行校验。Mutating和Validation之间还有一个名为ObjectSchema Validation的操作，用于进行一些对于资源对象通用的校验，例如Pod中所有容器的名字都要唯一等等。最后完成与etcd之间的交互。

认证(Authentication)

所有Kubernetes集群都有两类用户:由Kubernetes管理的服务账号和普通用户

尽管无法通过API调用来添加普通用户，Kubernetes仍然认为能够提供由集群的证书机构签名的合法证书的用户是通过身份认证的用户。基于这样的配置，Kubernetes使用证书中的 'subject'的通用名称(Common Name)字段（例如，"/CN=bob")来确定用户名。接下来，基于角色访问控制(RBAC)子系统会确定用户是否有权针对某资源执行特定的操作。

与此不同，Service Account是Kubernetes API所管理的用户。它们被绑定到特定的名字空间，或者由API服务器自动创建，或者通过API调用创建。服务账号与一组以Secret保存的凭据相关，这些凭据会被挂载到Pod中，从而允许集群内的进程访问Kubernetes APl。

认证(Authentication)

service account样例

持有者令牌会挂载到 Pod中可预知的位置，允许集群内进程与API服务器通信。服务账号也可以使用Pod规约的serviceAccountName字段显式地关联到Pod 上。

service-account-token的secret资源包含的数据有三部分:

ca.crt:这是API Server的CA公钥证书，用于Pod中的Process对APl Server的服务端数字证书进行校验时使用的;

Namespace:这是Secret所在namespace的值的base64编码: #echo -n“kube-system" |base64 => "a3ViZS1zeXNOZWO="

token:该token就是由service-account-key-file的值签署(sign)生成。

已签名的JWT可以用作持有者令牌，并将被认证为所给的服务账号。

服务账号被身份认证后，所确定的用户名为system:serviceaccount:<名字空间>:<服务账号>，并被分配到用户组system:serviceaccounts和system:serviceaccounts:<名字空间>。

认证(Authentication)

Service Account

Service Account Token是一种比较特殊的认证机制，适用于上文中提到的pod内部服务需要访问apiserver的认证情况，默认enabled.Service Account为k8s默认开放认证方式

Kube-apiserver的启动参数’—service-account-key -file=key.pem'指定pem文件，用以生成bearer token;'—sevice-count-ookup=true/fase'表示在删除service account后其token是否被吊销

认证(Authentication)

ServiceAccount Admisson Controller

当Pod被创建或更新时，它会同步地修改Pod。当Pod被创建或更新时它会进行以下操作:

设置ServiceAccount: 如果该Pod没有指定，则设置default ServiceAccount 。

校验指定ServiceAccount是否存在:否则拒绝该Pod。

自动挂卷选项:若automountServiceAccountToken都为设置为false，使用已有，否则为Pod 创建一个volume。

创建volumeSource挂载目录:如果前一步中为服务账号令牌创建了卷，则为Pod中的每个容器添加一个volumeSource，挂载在其/var/run/secrets/kubernetes.io/serviceaccount目录下。

设置imagePullSecrets:如果Pod 不包含imagePullSecrets设置，将ServiceAccount所引用的服务账号中的imagePullSecrets 信息添加到Pod中。

TokenController

作为kube-controller-manager的一部分运行，以异步的形式工作。其职责包括:

监测ServiceAccount 的创建并创建相应的Secret以允许访问API。

监测ServiceAccount的删除并删除所有相应的Secret。

监测ServiceAccount的Secret添加，保证相应的ServiceAccount存在，如有需要，向Secret中添加令牌。

监测服务账号令牌Secret 的删除，从相应的ServiceAccount中移除引用。

list,watch k8s apiserver对于命名空间的创建、删除;在新创建的名称空间下创建一个名为”default”的service account;

认证(Authentication)

前面已经对k8s的认证过程有一个初步的了解，接下来对认证流程源码进行分析

Kube-apiserver在权限相关代码从k8s.io/apiserver/pkg/server/config.go中DefaultBuildHandlerChain函数开始处理请求中的认证逻辑，源码如右侧(图1)

DefaultBuildHandlerChain中包含了多种filter (如认证，链接数检验，RBAC权限检验等)，在WithAuthentication中完成认证流程，在WithAuthorization中完成鉴权流程。

WithAuthentication函数中通过auth.AuthenticateRequest(req)处理请求。

认证(Authentication)

如图下侧，AuthenticateRequest按照handler的顺序进行认证，只要有一个成功就返回。那么Handler从哪里注册的呢?

在kube-apiserver启动时，初始配置过程中，会根据kube-apisver的启动参数确定启用的认证能力。关键函数在ToAuthenticationConfig，包含了按照配置启用相关能力选择，后续就会根据配置初始化相关的认证能力。

认证(Authentication)

本次课程重点讲解X509和ServiceAccount，所以后面重点解析这两类认证的实现。初始化配置如下代码所示。

可以看到X509从启动参数配置中加载证书以及ServiceAccount认证所需要使用的客户

鉴权(Authorization)

鉴权模块

Node - 一个专用鉴权组件，根据调度到kubelet上运行的Pod为kubelet授予权限。

ABAC-基于属性的访问控制(ABAC)定义了一种访问控制范型，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、对象，环境属性等）。

RBAC-基于角色的访问控制(RBAC)是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看、创建或修改文件。

被启用之后，RBAC(基于角色的访问控制)使用rbac.authorization.k8s.io API组来驱动鉴权决策，从而允许管理员通过Kubernetes API动态配置权限策略。

要启用RBAC，请使用--authorization-mode = RBAC启动API服务器。

Webhook - WebHook是一个HTTP回调:发生某些事情时调用的HTTP POST;通过HTTP POST进行简单的事件通知。实现WebHook的Web应用程序会在发生某些事情时将消息发布到URL。

这里我主要学习总结最常用的鉴权方式—RBAC

鉴权(Authorization)

RBAC的鉴权策略可以利用kubectl或者Kubernetes APIl直接进行配置。RBAC可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC在Kubernetes 中被映射为API资源和操作。RBACAPl声明了四种Kubernetes 对象: Role、ClusterRole、RoleBinding和ClusterRoleBinding。你可以像使用其他Kubernetes 对象一样。

命名空间及权限详解

Role和ClusterRole

1. Role是只作用于命名空间级别的，用于定义命名空间内资源权限集合。

2. ClusterRole则用于集群级别的资源权限集合，它们都是标准的API资源类型。

3.一般来说，ClusterRole的许可授权作用于整个集群，因此常用于控制Role无法生效的资源类型，这包括集群级别的资源（如Nodes)、非资源类型的端点(如/ healthz)和作用于所有命名空间的资源（例如跨命名空间获取任何资源的权限)。

RoleBinding和ClusterRoleBinding

1. RoleBinding用于将Role上的许可权限绑定到一个或一组用户之上，它隶属于且仅能作用于一个命名空间。绑定时，可以引用同一名称中的Role，也可以引用集群级别的ClusterRole。

2. ClusterRoleBinding则把ClusterRole中定义的许可权限绑定在一个或一组用户之上，它仅可以引用集群级别的ClusterRole。

3. Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如图所示。

鉴权(Authorization)

需要理解RBAC一些基础的概念和思路，RBAC是让用户能够访问Kubernetes APl资源的授权方式。

role

角色是一系列权限的集合，例如一个角色可以包含读取Pod 的权限和列出Pod的权限，ClusterRole 跟Role类似，但是可以在集群中到处使用(Role是namespace一级的)。

role binding

RoleBinding把角色映射到用户，从而让这些用户继承角色在namespace 中的权限。ClusterRoleBinding 让用户继承ClusterRole在整个集群中的权限。另外还要考虑clusterroles和cluster role binding,cluster role和cluster role binding方法跟role和role binding一样，出了它们有更广的scope。

Kubernetes中的RBAC

RBAC现在被Kubernetes深度集成，并使用他给系统组件进行授权。System Roles一般具有前缀system:;很容易识别。