K8s API访问控制

    在身份认证阶段，最重要的就是辨别用户的身份了，API Server需要从请求中获取有关于用户身份的信息。通常用户身份信息可以通过User或Group来定义，但是K8s中并没有相关的定义，所以无法通过API Server对User或Group进行管理。K8s认为User、Group这类信息由外部系统来管理，自己并不负责管理和设计，这样做的好处在于可以避免重复定义用户模型，更方便第三方用户权限平台进行对接。

  当向API Server发送请求时，认证插件将以下属性与请求者相关联：

所有的值对身份认证系统都是不透明的，并只有在由authorizer授权者解释时才具有重要意义。您可以一次性启用多种身份验证方式。通常使用至少两种认证方式。

当启用了多个认证模块时，第一个认证模块成功认证后将不会进行第二个模块的认证。API Server不会保证认证的顺序。

与其他身份验证协议（LDAP、SAML、Kerberos、x509 方案等）的集成可以使用身份验证代理或身份验证 webhook来实现。

    为什么K8s中会有Service Account和普通用户这两种形式呢？因为与API Server服务交互实际上有两种类型东西，一种是真实的人类用户，另一类就是程序。因此，真实的人类用户对应的就是普通用户账号，而程序对应的就是Service Account了。

    API Server请求被绑定到Service Account或普通用户上，或者作为匿名请求对待。这意味着集群内部或外部的每个进程，无论是在服务器上输入 kubectl 的用户、节点上的 kubelet或web控制面板的成员，都必须在向 API Server 发出请求时进行身份验证，否则被视为匿名用户。

    Service Account是由 K8s API管理的帐户，它不是给K8s集群的用户（系统管理员、运维人员、租户用户等）使用的，而是给运行在Pod里的进程用的，它为Pod里的进程提供了必要的身份证明。Service Account都绑定到了特定的 namespace，并由 API Server 自动创建或者通过 API 调用手动创建。一个Pod必须要以某一个Service Account的身份去运行，一个Service Account对应着一个Secret，一个Secret保存着一个Token和公钥文件，从而允许 pod 与API Server之间的调用。Secret从属于Service Account资源对象，属于Service Account的一部分，在一个Service Account对象里面可以包括多个不同的Secret对象，分别用于不同目的的认证活动。

    我们进入pod中，查找/var/run/secrets/kubernetes.io/serviceaccount下的token文件，即可看到该pod对应服务账户的Token，该Token是jwt格式的字符串，如图所示：

那么，这个Token是怎么生成的呢？

    该Token是动态生成的，是由kube-controller-manager进程调用API Server的私钥（/etc/kubernetes/manifests/kube-controller-manager.yaml配置文件--service-account-private-key-file参数指定的文件）签名生成的一个JWT格式的Token。API Server接收到客户端发来的Token后，会再次用私钥（/etc/kubernetes/manifests/kube-controller-manager.yaml配置文件--service-account-private-key-file参数指定的文件）对该Token进行校验。

    我们查看所有的ServiceAccount，发现在每个命名空间下都存在一个名为default的默认ServiceAccount对象。

    在这个Service Account里面有一个名为Secrets的可以作为Volume被挂载到Pod里的Secret，Pod启动时，这个Secrets会自动被挂载到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权。

    一个Service Account可以包含多个secret，名为secrets的secret用于访问API Server的secret，也被称为ServiceAccountSecret；名为imagePullSecrets的secret用于下载容器镜像时的认证，但是由于镜像库通常运行在Insecure模式下，所以这个secret为空；用户还可以自定义其他的secret。

    如果一个Pod在定义时没有指定spec.serviceAccountName属性，则系统会自动将其赋值为default，即大家都使用同一个命名空间中的默认Service Account。如果某个Pod需要使用非default的Service Account，则需要在定义时指定spec.serviceAccountName为"服务账户名"。

Service Account的正常工作离不开以下准入控制器：

• Service Account准入控制器

• Token准入控制器

    关于准入控制器，我们会后文章最后进行讲解。

    注意：由于 Service Account 的 token 存储在 secret 中，所以具有对这些 secret 的读取权限的任何用户都可以作为 Service Account 进行身份验证。授予 Service Account 权限和读取 secret 功能时要谨慎。

    普通用户就是个人用户，比如某个研发人员或外部应用的账号。但是K8s并没有相应的资源对象或者API来支持常规的个人用户。拥有K8s集群的CA证书签名的有效证书，个人用户就可以访问K8s集群了。在这种情况下，证书中的subject会被API Server服务解析成一个用户。比如，证书中的subject的内容为：O=yunwei,CN=lisi。其中CN(Common Name)lisi会被解析为用户，而O(Organization Name)yunwei会被解析为用户所在的组。

K8s内置了一组系统级别的用户，以“system：”开头，如下：

执行如下命令然后查看Users列即可查看K8s默认创建的User。

    当一个请求没有携带任何的认证信息时，它会自动获得用户名：system:anonymous和用户组 system:unauthenticated，我们可以配置分配特定的权限给这种匿名用户，适用于想要公开一些不敏感的资源等场景。

    同外部用户一样，Group 也是一种外部的概念，在X509客户端证书认证的方式中，Group 名字就是证书的组织名O（Orgnization）。

    K8s内置了一组系统级别的组，以“system：”开头，如下：

    执行如下命令然后查看Groups列即可查看K8s默认创建的Group。

    K8s需要PKI（public key infrastructure，公钥基础设施）证书来基于TLS的安全的认证。如果是使用kubeadm来初始化的集群，则kubeadm会帮助你自动生成集群所需要的各类证书。kubeadm会将证书放置在/etc/kubernetes/pki目录下，而包含管理员证书的配置文件admin.conf会放置到/etc/kubernetes目录下。

    k8s使用x509证书中CN(Common Name)以及O(Organization)字段对应k8s中的user和group，将Authentication和RBAC Authorization结合到了一起，巧妙地将Control Plane中的各个核心User和Group、与操作权限（ClusterRole）进行了集群绑定（ClusterRoleBinding）。

    这种认证采用的数据结构是由JWT Token类型的，一般的形式是在HTTP Authroziation头部添加Bear Token，每个Bearer Token都对应一个用户名。客户端发起API调用请求时，API Server就能识别用户身份了。比如pod所对应的Service Account采用的就是这种形式，Token采用的是RS256非对称加密算法进行加密。

    当用户认证通过后，下一步就是授权操作了。API Server服务目前支持以下几种授权策略：

    通过API Server的配置文件/etc/kubernetes/manifests/kube-apiserver.yaml的参数--authorization-mode可配置多种授权策略，用逗号分隔即可。在通常情况下，我们会设置授权策略为Node,RBAC，如图所示。API Server在收到请求后，会读取该请求中的数据，生成一个访问策略对象，然后API Server会将这个访问策略对象和配置的授权模式逐条进行匹配，第一个被满足或拒绝的授权策略决定了该请求的授权结果，如果匹配的结果是禁止访问，则API Server会终止API调用流程，并返回客户端的错误调用码。

基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定， 允许你通过 K8s API 动态配置策略。RBAC在K8s 1.8版本时升级为GA稳定版本，并作为kubeadm安装方式下的默认授权选项。

RBAC具有如下优势：

• 对集群中的资源和非资源权限均有完整的覆盖。

• RBAC的权限配置通过几个API对象即可完成，同其他API对象一样，可以用kubectl或API进行操作。

• 可以在运行时进行调整，无须重新启动API Server。

在RBAC授权中，有如下概念：

最后就是将主体与角色进行绑定，以获得特定的权限，如下图所示：

    在RBAC管理体系中，K8s引入了4个资源对象：Role、ClusterRole、RoleBinding和ClusterRoleBinding。同其他API资源对象一样，用户可以使用kubectl或者API调用等方式操作这些资源对象。

    Role 或 ClusterRole 中包含一组代表相关权限的规则，这些规则设置的权限都是许可形式的，不可以设置拒绝形式的规则。Role设置的权限将会局限于命名空间范围内，在你创建 Role 时，你必须指定该 Role 所属的名字空间。如果需要在集群级别设置权限，就需要使用ClusterRole了。

以下是一个Role的yaml定义：

    上述定义的Role的name是test-role，这个Role的权限是可以对所有apiGroups下面的资源名为“pods”的资源进行get、list、watch和delete的操作。但是需要注意的是限定在test的命名空间范围内。

Role资源对象主要通过rules字段来描述它的功能，rules字段是rule的列表，每个rule是一组作用于不同apiGroup资源上的一组操作的集合，每一个rule包含如下几个关键字段：

    从命名上来看，ClusterRole的处理范围要比Role大，因为Role的范围是namespace，而ClusterRole的范围是Cluster。

ClusterRole主要适用以下场景：

下面是一个ClusterRole的yaml定义：

    上述ClusterRole定义的是一个name为test-ClusterRole，拥有对所有apiGroup下的资源类型为secrets的资源进行get、list、watch的操作，并且他没有限定namespace。

apiGroups

resources

verbs

RoleBinding有两个比较重要的根节点，一个是subjects，描述了需要绑定的主体，有user、group和service account；另一个是roleRef，描述了要绑定的Role。

RoleBinding本身会被namespace所影响，用于某个namespace内的授权，如果它与Role进行绑定，就需要保持一致的namespace；

RoleBinding除了能够和Role绑定，也能和ClusterRole绑定，这个操作的含义是：对目标主体在其所在的命名空间授予在ClusterRole中定义的权限。如下将集群角色test-ClusterRole与用户test进行绑定，虽然test-ClusterRole是一个集群角色，但因为RoleBinding的作用范围为命名空间test，所以用户test只能读取命名空间test中的secret资源对象，而不能读取其他命名空间中的secret资源对象。

ClusterRoleBinding用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许test组的用户读取任意命名空间中的secret资源对象：

在集群角色绑定（ClusterRoleBinding）中引用的角色只能是集群级别的角色（ClusterRole），而不能是命名空间级别的Role。

一旦通过创建RoleBinding或ClusterRoleBinding与某个Role或ClusterRole完成了绑定，用户就无法修改与之绑定的Role或ClusterRole了。只有删除了RoleBinding或ClusterRoleBinding，才能修改Role或ClusterRole。Kubernetes限制roleRef字段中的内容不可更改，主要有以下两个原因。

    Node授权策略用于对kubelet发出的请求进行访问控制，与用户的应用授权无关，属于K8s自身安全的增强功能。简单来说，就是限制每个Node只访问它自身运行的Pod及相关的Service、Endpoints等信息；也只能受限于修改自身Node的一些信息，比如Label；也不能操作其他Node上的资源。而之前用RBAC这种通用权限模型其实并不能满足Node这种特殊的安全要求，所以将其剥离出来定义为新的Node授权策略。Node授权可以与NodeRestriction准入控制插件相结合使用来进行Node隔离。

Node授权器允许kubelet执行的API操作包括：

在K8s 1.6中，使用RBAC授权模式时，system:node群集角色（role）自动绑定到该system:nodes组。

在K8s 1.7中，由于Node授权器实现了相同的目的，因此不再支持system:nodes组与system:node角色的自动绑定，从而有利于对secret 和configmap访问的附加限制。

在K8s 1.8中，将不会创建binding。

使用RBAC时，将继续创建system:node集群角色，以便兼容使用deployment将其他users或groups绑定到集群角色的方法。

客户端的请求通过认证Authentication和授权Authorization后，会进入到准入控制AdmissionControl关卡。准入控制可以执行验证Validating和变更Mutating等操作。准入控制器限制创建、删除、修改对象的请求，也可以阻止自定义动作，但是准入控制器不会也不能阻止get、watch、list对象的请求。

准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 某些准入控制器既可以是变更准入控制器又可以是验证准入控制器。如果两个阶段之一的任何一个控制器拒绝了某请求，则整个请求将立即被拒绝，并向最终用户返回错误。最后，除了对对象进行变更外，准入控制器还可能有其它的作用，比如将相关资源作为请求处理的一部分进行变更。 增加配额用量就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。

那么可能很多人会问了，为什么需要准入控制呢？

原因在于K8s 的若干重要功能(如创建、删除等高危操作)都要求启用一个准入控制器，以便正确地支持该特性。 因此，没有正确配置准入控制器的 K8s API 服务器是不完整的，它无法支持你所期望的所有特性。

那么如何启用一个准入控制器呢？

在K8s 1.9及之前的版本中使用的参数是--admission-control，其中的内容是顺序相关的；在Kubernetes1.10及之后的版本中使用的参数是--enable-admission-plugins，该参数标志接受一个准入控制插件列表（以逗号分隔的）， 这些准入控制插件会在集群修改对象之前被调用，发送给API Server的任何请求都需要通过列表中每个准入控制器的检查，检查与准入控制器的顺序无关。

如下，下面的参数标准启用 NodeRestriction、NamespaceLifecycle 和 LimitRanger 准入控制插件：

    如果想关闭准入控制器的话，可以使用disable-admission-plugins 参数标志，该参数会将传入的（以逗号分隔的） 准入控制插件列表禁用，即使是默认启用的插件也会被禁用。

如下，下面的参数标准禁用 PodNodeSelector 和 AlwaysDeny准入控制插件。

除了静态编译的Admission插件，也可以通过Webhook方式对接外部的AdmissionWebhook服务，实现与Admission插件一样的功能。但Webhook方式更加灵活，能够在API Server运行时修改和配置动态更新控制策略。

    不过，相对于Admission Control插件来说，使用Admission Webhook要复杂得多，除了需要开发一个Admission Webhook Server实现HTTP回调的逻辑，还需要创建一个对应的ValidatingWebhookConfiguration资源对象配置文件，如果Admission Webhook需要与API Server进行认证，则还需要创建对应的AdmissionConfiguration配置文件。

    该准入控制器插件限制了kubelet 可以修改的 Node 和 Pod 对象。 为了受到这个准入控制器的限制，kubelet 必须使用在 system:nodes 组中的凭证， 并使用 system:node: 形式的用户名。 这样，kubelet 只可修改自己的 Node API 对象，只能修改绑定到自身节点的 Pod 对象。

并且该准入控制器插件不允许 kubelet 更新或删除 Node API 对象的污点。

NodeRestriction 准入控制器插件可防止 kubelet 删除其 Node API 对象， 并对前缀为 kubernetes.io/ 或 k8s.io/ 的标签的修改对 kubelet 作如下限制：

    以 kubernetes.io 或 k8s.io 为前缀的所有其他标签都限制 kubelet 使用，并且将来可能会被 NodeRestriction 准入插件允许或禁止。将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集。

    Service Account准入控制器实现了ServiceAccount 的自动化，如果你打算使用 K8s 的 ServiceAccount 对象，强烈推荐为 K8s 项目启用此准入控制器。

    Service Account 准入控制器的工作相对简单，它会监听Service Account和Namespace这两种资源对象的事件，如果在一个Namespace中没有默认的Service Account，那么它会为该Namespace创建一个默认的ServiceAccount对象，这就是在每个Namespace下都有一个名为default的Service Account的原因。

    针对Pod新增或修改的请求，Service Account准入控制器会验证Pod里的Service Account是否合法，并做出如下控制操作：

    在K8s 1.6版本以后，我们可以禁止自动创建ServiceAccount对应的Secret了，在ServiceAccount的yaml文件中增加automountServiceAccountToken：false属性即可，同时可以在某个Pod的yaml文件中增加此属性，以实现同样的效果。

    Token准入控制器作为 kube-controller-manager 的一部分运行，以异步的形式工作。

    其职责包括：

参考：

用户认证：

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/

使用 RBAC 鉴权：

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/#core-component-roles

使用 Node 鉴权：

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/node/

kubernetes集群安全机制：

https://zhuanlan.zhihu.com/p/468010077

Kubernetes 集群权限管理RBAC：

https://blog.csdn.net/qq_34556414/article/details/112909522

Kubernetes 中的用户与身份认证授权：

https://www.kancloud.cn/chriswenwu/g_k8s/1006520

- END -