前言：K8S 提供了丰富的认证和受权机制，能够知足各类场景细粒度的访问控制。本文会介绍 k8s 中的用户认证、受权机制，并经过例子阐述 kubeconfig 的生成和原理，最后会列举常见的证书问题，如过时、吊销、租户控制等。本文属于科普 + 实践，不涉及 apiserver 中代码实现。node
两种用户mysql
k8s中的客户端访问有两类用户:nginx
普通用户（Human User），通常是集群外访问，如 kubectl 使用的证书程序员
service account: 如集群内的 Podweb
有什么区别呢？面试
k8s 不会对 user 进行管理，并不存储 user 信息，你也不能经过调用k8s api来增删查这个 user。你能够认为这个 user 指的就是公司内的人员，通常须要对接内部权限系统，user 的增删操做都是在 k8s 外部进行，k8s 只作认证不作管理。sql
k8s 会对serviceaccount 进行管理，他的做用是给集群内运行的 pod 提供一种认证的方式，若是你这个 pod 想调用apiserver操做一些资源如获取 node列表，就须要绑定一个serviceaccount帐户给本身，并为这个serviceaccount赋予必定的权限，这样就作到了实体和权限的分离，也就是后面会提到的 rbac 受权。json
做用范围：bootstrap
User独立在 K8S 以外，也就是说User是能够做用于全局的，跨 namespace，而且须要在全局惟一api
ServiceAccount是K8S的一种资源，是存在于某个namespace之中的，在不一样namespace中能够同名，表明了不一样的资源。
举例说明：
为 user 生成 kubeconfig
一个同事张三都想要一份集群的 kubeconfig 用来平常 kubectl 操做集群，但限定只能操做名为 test 的 namespace，公司有独立的权限系统，他的用户 ID 是惟一的，叫zhangsan。接下来手动为这个用户生成 kubeconfig
生成证书：
获得：
zhangsan.pem
zhangsan-key.pem
接下来为 zhangsan 受权，首先生成一份角色：test-role, 权限为test 的命名空间下的全部资源的全部操做权限
而后将这个角色role绑定到zhangsan这个 user 上，表明 zhangsan 拥有了这个 role 的权限
为张三生成专属的 kubeconfig 文件，名为zhangsan.conf
获取 test 下全部的 pod
若是获取其余 namespace 下的pod，则报权限错误
为 pod 建立 serviceaccount
以 metrics-server的 pod 为例，须要对 pod、node、ns 等资源进行 get list操做，所以权限配置为：
pod 的 yaml 配置中声明serviceAccountName为metrics-server
以上是 user用户使用 kubeconfig、pod 使用 serviceaccount 的示例，pod 使用serviceaccount是比较好理解的，但其实 kubeconfig 也能够直接用serviceaccount来生成，不必定非得用 user，只是大多数状况下，kubeconfig 的管理是和用户的声明周期一致的，即子用户能够申领一份本身的 kubeconfig，管理员能够随时吊销或者禁用子用户 kubeconfig 的效力。这个在后面的”多租户下的kubeconfig“中会提到。
三种机制
谈 k8s 的认证和访问控制，通常都会看到这张图：
k8s 中全部的 api 请求都要经过一个 gateway 也就是 apiserver 组件来实现，是集群惟一的访问入口。既然是 gateway，最基础的功能就是 api 的认证 + 鉴权了。对应了图上的步骤1和2，而 k8s 中还提供了第 3 步的 admission Control（准入控制），能够更方便地拦截、校验资源请求。
三种机制：
一、认证：Authentication，即身份认证。检查用户是否为合法用户，如客户端证书、密码、bootstrap tookens和JWT tokens等方式。
二、鉴权：Authorization，即权限判断。判断该用户是否具备该操做的权限，k8s 中支持 Node、RBAC（Role-Based Access Control）、ABAC、webhook等机制，RBAC 为主流方式
三、准入控制：Admission Control。请求的最后一个步骤，通常用于拓展功能，如检查 pod 的resource是否配置，yaml配置的安全是否合规等。通常使用admission webhooks来实现
1-2-3 所有经过后api 请求会被处理，在 k8s 中也就意味着资源变动能够落库到 etcd。
K8S 中的认证
上面提到 k8s 并不存储 user，只知道一个 user 名称，所以 user 在访问api 时怎么作的认证？
kubernetes 支持不少种认证机制，包括：
X509 client certs
Static Token File
Bootstrap Tokens
Static Password File
Service Account Tokens
OpenId Connect Tokens
Webhook Token Authentication
Authticating Proxy
Anonymous requests
User impersonation
Client-go credential plugins
前面提到的 user 生成 kubeconfig就是X509 client certs方式， 而 metric-server 就是Service Account Tokens方式。
X509 client certs
即客户端证书认证，X509 是一种数字证书的格式标准，是 kubernetes 中默认开启使用最多的一种，也是最安全的一种，api-server 启动时会指定 ca 证书以及 ca 私钥，只要是经过同一个 ca 签发的客户端 x509 证书，则认为是可信的客户端，kubeadm 安装集群时就是基于证书的认证方式。
客户端证书认证叫做 TLS 双向认证，也就是服务器、客户端互相验证证书的正确性，在都正确的状况下协调通讯加密方案。apiserver 、controller-manager、scheduler、kubelet 等组件之间的交互，通常也是基于X509的客户端认证方式，目前最经常使用的 X509 证书制做工具备 openssl、cfssl ，上面生成 kubeconfig 时用到就是 cfssl 工具签发的证书。
仍是举个例子，在手动部署 k8s 集群时须要作的证书操做，若是你已经熟悉这个过程或者用了 kubeadm 等部署工具，能够跳过这一段。
一、基础证书生成
ca-config.json
建立用来生成 CA 文件的 JSON 配置文件，这个文件后面会被各类组件使用，包括了证书过时时间的配置，expiry字段
ca-csr.json
建立用来生成 CA 证书签名请求（CSR）的 JSON 配置文件
生成基础 ca 证书
建立自签名 CA 证书：这里只须要ca-csr.json文件，执行后会生成三个文件：
ca.csr：证书签名请求，通常用于提供给证书颁发机构，自签的就不须要了
ca.pem：证书，公共证书
ca-key.pem：CA密钥
二、生成 apiserver 证书
apiserver-csr.json
hosts列表不只包含了三台 master 机器的ip，还包括了 对应的负载均衡的 ip和外网 ip（若是有的话），以及 kubernetes 的 svc IP：172.18.0.1
这个 ip 是 svc ip range 中的第一个 ip，若是没有这个 ip，集群内的 pod 将没法经过 serviceaccount 的形式访问 apiserver 并鉴权，会报证书错误。
建立apiserver 的 CA 证书：这里须要4 个文件
apiserver-csr.json：apiserver的证书配置
ca.pem：基础公钥
ca-key.pem：基础私钥
ca-config.json：配置文件，如过时时间
执行后会生成三个文件：
apiserver.csr
apiserver.pem
apiserver-key.pem
** 使用证书**
Service Account Tokens
也就是 service account 使用的认证方式。
你会发现x509的认证方式比较复杂，须要作不少证书，若是我在集群中部署了一个 pod，好比一些 operator，想访问apiserver获取集群的一些信息，甚至对集群的资源进行改动，这种认证属于 k8s 管理范畴，所以 k8s 定义了一种资源serviceaccounts来定义一个 pod 应该拥有什么权限。
serviceaccounts 是面向 namespace 的，每一个 namespace 建立的时候，kubernetes 会自动在这个 namespace 下面建立一个默认的 serviceaccounts，而且这个 serviceaccounts 只能访问该 namespace 的资源。serviceaccounts 和 pod、service、deployment 同样是 kubernetes 集群中的一种资源，用户能够建立本身的serviceaccounts。
service account 主要包含了三个内容：namespace、token 和 ca
namespace: 指定了 pod 所在的 namespace
token: token 用做身份验证
ca: ca 用于验证 apiserver 的证书
每一个 service account 都对应一个 secret，这三个信息就存放在这个 secret 里，以 base64 编码。service account 经过 mount 的方式保存在 pod 的文件系统中，其三者都是保存在 /var/run/secrets/kubernetes.io/serviceaccount/目录下。
kubeconfig 的生成与含义
kubeconfig 是用来访问 k8s 集群的凭证，生成 kubeconfig 的步骤很简单但参数不少，这里以生成 admin 的 kubeconfig 为例，解释各参数的含义。
生成最高权限的 kubeconfig。
通常状况下集群建立以后，会先生成一份最高权限的 kubeconfig，即管理员角色，能够操做集群的全部资源，并为其余用户建立或删除权限，能够称之为 admin 证书，生成方式是：
admin-csr.json
admin 证书
生成 admin.conf，即最高权限的 kubeconfig
集群参数
本段设置了所须要访问的集群的信息。
使用 set-cluster 设置了须要访问的集群，如上为 kubernetes 这只是个名称，实际为 –server 指向的 apiserver 所在的集群。
–certificate-authority 设置了该集群的公钥
–embed-certs 为 true 表示将 –certificate-authority 证书写入到 kubeconfig 中
–server 则表示该集群的 apiserver 地址
用户参数
本段主要设置用户的相关信息，主要是用户证书。
用户名: zhangsan
证书: /etc/kubernetes/ssl/zhangsan.pem
私钥: /etc/kubernetes/ssl/zhangsan-key.pem
这一步操做是指客户端的证书首先要通过集群 CA 的签署，不然不会被集群承认，认证就失败。
此处使用的是 客户端 x509 认证方式，也可使用token认证，如kubelet的 TLS Boostrap机制下的bootstrapping 使用的就是 token 认证方式
上下文参数
集群参数和用户参数能够同时设置多对，而上下文参数就是集群参数和用户参数关联起来。
上面的上下文名称为 kubenetes，集群为 kubenetes(apiserver 地址对应的集群)，用户为zhangsan，表示使用 zhangsan 的用户凭证来访问
kubenetes 集群
最后使用 kubectl config use-context kubernetes 来使用名为 kubenetes 的环境项来做为配置。
若是配置了多个环境项，能够经过切换不一样的环境项名字来访问到不一样的集群环境。
kubeconfig 的认证过程
正向生成 kubeconfig 咱们已经作完了，apiserver 认证请求时，如何解析 kubeconfig 文件的内容呢？
咱们能够看下 kubeconfig 的内容：
除了 context，里面有三个证书字段，都是 base64 编码后的内容
certificate-authority-data: server 端的证书，用于验证 apiserver 的合法性
client-certificate-data: 客户端证书
client-key-data: 客户端私钥
能够提取出来 certificate-authority-data 的内容放到一个文件cert.txt，而后base64解码
ertificate-authority-data：
获得的内容其实就是 ca.pem 即服务端证书，apiserver 的证书也是基于ca.pem签发，由于 TLS 是双向认证，apiserver 在认证 kubectl请求时，kubectl 也须要验证 apiserver 的证书，防止中间人攻击，验证的字段就是certificate-authority-data
client-certificate：
由于 k8s 没有 user 这种资源，所以在使用 kubeconfig 访问时，身份信息就“隐藏”在client-certificate的数据中，咱们来查看一下。
将 kubeconfig 中的client-certificate-data的内容放在一个文件 client.txt 中，而后解码：
查看证书内容：
输出内容能够看到Subject: organization=system:masters, common_name=kubernetes-admin
apiserver 验证、解析请求，获得 system:masters 的http上下文信息，并传给后续的authorizers来作权限校验。
O 和 CN 的含义
“O”：Organization, apiserver接到请求后从证书中提取该字段做为请求用户所属的组 (Group)
“CN”：Common Name，apiserver从证书中提取该字段做为请求的用户名 (User Name)
在admin-csr.json中， admin使用了system:masters做为组 (Group)
k8s 预约义了 RoleBinding:cluster-admin 将 Group system:masters 与 Role cluster-admin 绑定，该 Role 授予了调用 k8s 相关 API 的权限，权限极高。
即：
Group: system:masters
ClusterRole: cluster-admin
ClusterRoleBinding: cluster-admin
k8s 核心组件的默认权限
admin权限：system:masters组，clusterrole 和 rolebinding 都叫 cluster-admin
kubelet: system:nodes组，clusterrole 和 rolebinding 都叫system:nodes，下同
kube-proxy: system:kube-proxy组
scheduler: system:kube-scheduler组
controller-manager: system:kube-controller-manager组
对应关系如图所示
即 k8s 全部自身组件使用的权限都是基于内置的 clusterrole，生成出来的 kubeconfig 被各组件进程使用，权限都是默认已有 role，若是但愿本身建立 role ，就要使用 rbac 受权了
至此，咱们应该知道了kubeconfig 的生成流程、验证方式，以及为何采用了 admin.conf 做为kubeconfig，kubectl就能拥有最高权限。下面是一幅示意图
K8S 中的受权
不管是 user的x509认证 仍是 service account的 token认证，认证完后，都要到达第 2 步：受权，
K8S 目前支持了以下四种受权机制：
Node
ABAC
RBAC
Webhook
用的最多的就是 RBAC，即基于角色作权限控制。
Node
仅 v1.7 版本以上支持 Node 受权，配合 NodeRestriction 准入控制来限制 kubelet，使其仅可访问 node、endpoint、pod、service 以及 secret、configmap、pv、pvc 等相关的资源，在 apiserver 中使用如下配置来开启
node 的鉴权机制：
RBAC
RBAC（Role-Based Access Control）是 kubernetes 中基于角色的访问控制，经过自定义角色并将角色和特定的 user，group，serviceaccounts 关联起来达到权限控制的目的。
RBAC 中有三个比较重要的概念：
Role: 角色，它实际上是一组规则，定义了一组对 Kubernetes API 对象的操做权限；
Subject: 被做用者，包括 user、group、service account，通俗来说就是认证机制中所识别的用户；
RoleBinding: 定义了“被做用者”和“角色”的绑定关系，也就是将用户以及操做权限进行绑定；
RBAC 其实就是经过建立角色(Role），经过 RoleBinding 将被做用者（subject）和角色（Role）进行绑定。下图是 RBAC 中的几种绑定关系：
示例：
role:
权限声明：
apiGroups为“”表明全部核心资源即 v1 group
apiGroups为“*”表明全部group
指定 pod 下的子对象如 kubectl logs xx，在resources中写为pods/log
对于 CRD 的权限能够定义为：
deployment、sts 等不在核心组，
以 prometheus pod 所须要的权限为例：
K8S 中的准入控制
准入控制是请求的最后一个步骤，准入控制有许多内置的模块，能够做用于对象的 “CREATE”、”UPDATE”、”DELETE”、”CONNECT” 四个阶段。在这一过程当中，若是任一准入控制模块拒绝，那么请求马上被拒绝。一旦请求经过全部的准入控制器后就会写入 etcd 中。
准入控制是在 apiserver 中进行配置启用的：
kubectl api-versions |grep admission 来确认是否开启“admissionregistration.k8s.io/v1beta1”
准入控制的配置是有序的，不一样的顺序会影响 kubernetes 的性能。若须要对 kubernetes 中的对象作一些扩展，可使用准入控制，好比：建立 pod 时添加 initContainer 或者校验字段等。准入控制最常使用的扩展方式就是 admission webhooks，分两种
MutatingAdmissionWebhook：在对象持久化以前进行修改
ValidatingAdmissionWebhook：在对象持久化以前进行
istio就是经过 mutating webhooks 来自动将Envoy这个 sidecar 容器注入到 Pod 中去的：https://istio.io/docs/setup/kubernetes/sidecar-injection/。
admission webhooks是同步调用，须要部署webhook server，并建立对象ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration来指向本身的 server，以ValidatingAdmissionWebhook为例：
部署 webhook：
配置：ValidatingWebhookConfiguration
你须要等待几秒，而后经过经过Deployment或者直接建立Pod，这时建立Pod的请求就会被apiserver拦住，调用ValidatingAdmissionWebhook进行检查是否Admit经过。好比，上面的example-webhook是检查容器镜像是否以”gcr.io”为前缀的。
示例中的 webhook逻辑比较简单，只是检查下 image name，而后启动 http server
AdmissionWebhook 与 Initializers 的区别：
两者都能实现动态可扩展载入admission controller， Initializers是串行执行，在高并发场景容易致使对象停留在uninitialized状态，影响继续调度。Alpha Initializers特性在k8s 1.14版本被移除了，官方更推荐AdmissionWebhook；MutatingAdmissionWebhook是串行执行，ValidatingAdmissionWebhook是并行执行，性能更好。
证书吊销、过时更换
对于kubeconfig 这种 x509证书来讲，只要证书不泄露，能够认为是很安全的。可是颁发证书容易，却没有很好的方案注销证书、续期证书
吊销
想一下若是某个核心成员离职，该如何回收他的admin kubeconfig证书？或者不当心把 kubeconfig 泄露，如何让这个 kubeconfig 无效呢？
先看下封禁手段：
若是是离职，且 k8s 集群在内网环境，就算他把证书带出公司也不要紧，毕竟有内网访问限制。但若是是云上 k8s 集群，且开放了公网的入口，那么安全风险就很高了，kubeconfig 只是一个文件，你没法经过限制 ip 来源来封禁。
若是是转岗，封禁就比较困难了，仍然在内网环境，且 kubeconfig 通常在办公电脑上使用，即办公网络到服务内网，经过来源封禁是不可能的。
再看下证书吊销：
kubeconfig 证书不支持吊销，参考 ISSUE。准确的说 k8s 没有实现CRL（证书吊销列表）或 OCSP（在线证书状态协议），并无一个统一的地方管理这些证书，所以若是您的密钥被盗用，Kubernetes也没法在身份验证层知道。
如何解决这种问题：
从新签发证书，涉及到apiserver 等组件的重启
若是用了 rbac，封禁这个角色的权限
如何预防这种问题:
重要：不要使用最高权限的证书，不要使用自带权限的证书如 system:master，这种只适合kubelet 等组件使用，不适合用来签发 kubeconfig
不管是用 user 仍是 service account 来生成kubeconfig，都使用 rbac 来受权，这样就算 kubeconfig 丢失，也能够解除 clusterrolebinding来吊销权限。即管理给用户的受权，就变成管理clusterrolebinding了
证书的过时时间设置的短一点，如 1 个月就失效，将影响范围下降
合理规划主帐号和子帐户，如主帐户只容许有一份 admin 证书，其余子用户所有基于 rbac 来操做，甚至主帐户也能够用 rbac 来操做，只是权限特别大而已
集成外部认证系统
证书之因此没法吊销，是由于证书没有统一的认证中心，换句话，K8S只是定义了一些角色，并无实现用户管理、权限管理，所以专业的人作专业的事，接入认证系统才是生产环境严肃认真的解决方案。
Kubernetes支持集成第三方Id Provider（IdP），主流的如AD、LADP以及OpenStack Keystone等。通常都是基于 OpenID Connect（OIDC）Token 的认证和受权。
当前支持OpenID Connect的产品有不少，如：
Keycloak
UAA
Dex
OpenUnison
云厂商
证书续签
证书配置中有一个字段：”expiry”: “87600h”表明了证书的过时时间，到期后证书认证会失败。
kubeadm 建立的 Kubernetes 集群， apiserver、controller-manager、kubelete 等组件的证书默认有效期只有一年。
由于 k8s 版本迭代很快，官方推荐一年以内至少用 kubeadm 更新一次 Kubernetes 版本，同时会自动更新证书。
查看根 CA 证书的有效期，默认为 10 年：
查看当前证书有效期
从新签发证书:续签所有证书
也能够局部进行续签
如apiserver-etcd-client 、apiserver-kubelet-client、apiserver、etcd-healthcheck-client、etcd-peer、etcd-server、front-proxy-client
kubeadm alpha certs renew apiserver-etcd-client
若是不是 kubeadm 建立的集群，须要手动从新生成全部组件的证书
kubelet 从 v1.8.0 开始支持证书轮换，当证书过时时，能够自动生成新的密钥，并从 Kubernetes API 申请新的证书。
更换 apiserver 的 ip 或接入 nginx
若是由于机器故障，须要更换 apiserver 机器，则最好保持 ip 不变，不然证书须要重签，由于证书文件中声明了机器 ip和负载均衡 ip，若是访问时只用到了负载均衡 ip，那么机器 ip 能够不用声明，也不用担忧机器更换问题。
apiserver 接入 nginx
使用 nginx 的 passthrough，即 4 层转发 ssl 请求（配置简单，不须要apiserver证书）
方法二：使用七层正常的 http 转发
多租户集群中的的用户访问控制
rbac 权限控制是多租户集群中最基础的隔离手段，如基于 namespace 作租户隔离：
企业内部集群：也就是公司内的集群，是不少 k8s 客户的使用模式，由于集群在公司内网环境，网络风险可控，所以通常经过 namespace 对部门或产品线作隔离，如：
集群管理员：admin 角色，最高权限，能够扩、缩节点、升级集群，负责分配PV、租户等全局资源，通常是集群负责人。
租户管理员：op 角色，租户内（namespace）的最高权限，管理租户内的 rbac 权限、存储、计算资源等
普通用户：rd 角色，使用权限，根据开发测试角色不一样，功能不一样，可能会限制get/list/edit 等权限。
namespace 名通常和部门 id 是一致的，方便对接内部权限系统如 SSO，用户登陆后只能看到本身的 ns 下的业务 pod，同时能够下载本身的 kubeconfig 文件。
由于是经过 namespace 作 rbac 权限上的隔离，所以网络层面也要隔离 namespace，禁止互访，若是是跨租户的访问须要开放白名单。而存储和主机特权的隔离须要根据业务来决定，如seccomp/AppArmor/SELinux等是否容许业务使用。
通常状况下，namespace 的权限隔离能知足大多数企业 k8s 的需求，也是不少 paas 平台的租户实现方式。
saas & serveless 平台：通常出如今公有云上，该场景下用户没有 k8s 的概念，且不一样的服务能够混布在不一样的 namespace，如函数计算、AI 离线计算等，你只须要在 saas 控制台上点击部署 wordpress，选择软件版本，就能获得一个完整的博客平台，不须要关心后面的调度逻辑。
这种混布的业务若是有较高的安全需求，k8s 原生是没法知足的，还须要使用安全容器如 kata在容器运行时来强化租户安全。
其余场景下的认证需求
ingress
除了 k8s 集群的认证，ingress 也须要 https 证书，而 ssl 证书的续期管理都是一件麻烦事，若是你用的是云厂商，能够直接在云上购买 ssl 证书并绑定域名，而后经过 ingress-controller 实现 ingress 的功能，续签和证书管理都在云上进行，不须要本身关心。
若是你以为正规的 ca证书太贵，想用 Let’s Encrypt 等签发方式，又以为续签麻烦，可使用Cert manager来管理你的证书实现证书自动续签。
cert-manager + nginx-ingress-controller 结合能够参考这个文章：https://cert-manager.io/docs/tutorials/acme/ingress/
helm
在 helm2 中，helm 操做须要配合集群内部署 tiller 的 pod 来负责资源的建立，所以 tiller 须要赋予必定的权限，通常为了简单会为 tiller 的 pod 赋予 cluster-admin 的最高权限
tiller pod 运行在kube-system 下，拥有集群全部ns、全部资源的操做权限，不过你也能够限定tiller的使用范围，好比只能在特定的 namespace 下工做，如：
在特定 namespace 中部署 tiller，并仅限于在该 namespace 中部署资源
运行 helm init 来在 tiller-world namespace 中安装 Tiller
而在 helm3 中已经不须要 tiller 这个组件，只须要一个 helm 二进制，所以helm 命令使用的 kubeconfig 的权限，也就决定了可以在哪一个 namespace 操做什么资源，helm 权限和 kubectl 统一，更加方便。
欢迎你们关注个站：damon8.cn。
往期回顾
ArrayList、LinkedList 你真的了解吗？
浅谈 Java 集合 | 底层源码解析
Spring Cloud Kubernetes之实战一配置管理
Spring Cloud Kubernetes之实战二服务注册与发现
Spring Cloud Kubernetes之实战三网关Gateway
关注公众号，回复入群，获取更多惊喜！公众号(程序猿Damon)里回复 ES、Flink、Java、Kafka、MQ、ML、监控、大数据、k8s 等关键字能够查看更多关键字对应的文章。
点击 "damon8.cn" 获取更好的阅读体验！
❤️
给个
「在看」
，是对我最大的支持❤️
本文分享自微信公众号 - 程序猿Damon（Damon4X）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。