K8S 集群中的认证、授权与kubeconfig

亦凉 2022-11-16 15:28 731阅读 0赞

**两种用户**

**k8s中的客户端访问有两类用户:**

普通用户（Human User），一般是集群外访问，如 kubectl 使用的证书

service account: 如集群内的 Pod

**有什么区别呢？**

k8s 不会对 user 进行管理，并不存储 user 信息，你也不能通过调用k8s api来增删查这个 user。你可以认为这个 user 指的就是公司内的人员，一般需要对接内部权限系统，user 的增删操作都是在 k8s 外部进行，k8s 只做认证不做管理。

k8s 会对serviceaccount 进行管理，他的作用是给集群内运行的 pod 提供一种认证的方式，如果你这个 pod 想调用apiserver操作一些资源如获取 node列表，就需要绑定一个serviceaccount账户给自己，并为这个serviceaccount赋予一定的权限，这样就做到了实体和权限的分离，也就是后面会提到的 rbac 授权。

**作用范围：**

User独立在 K8S 之外，也就是说User是可以作用于全局的，跨 namespace，并且需要在全局唯一

ServiceAccount是K8S的一种资源，是存在于某个namespace之中的，在不同namespace中可以同名，代表了不同的资源。

**举例说明：**

为 user 生成 kubeconfig

一个同事张三都想要一份集群的 kubeconfig 用来日常 kubectl 操作集群，但限定只能操作名为 test 的 namespace，公司有独立的权限系统，他的用户 ID 是唯一的，叫zhangsan。接下来手动为这个用户生成 kubeconfig

生成证书：

![4bf73febf3d8d9dbe57c733fb9cc88a1.png][]

得到：

zhangsan.pem

zhangsan-key.pem

接下来为 zhangsan 授权，首先生成一份角色：test-role, 权限为test 的命名空间下的所有资源的所有操作权限

![d30233723246e5360d09bf30c977d932.png][]

然后将这个角色role绑定到zhangsan这个 user 上，代表 zhangsan 拥有了这个 role 的权限

![4d7f6a64d355c7d92615adef0d781b11.png][]

为张三生成专属的 kubeconfig 文件，名为zhangsan.conf

![81014832e2467b469f969b27a11f759f.png][]

获取 test 下所有的 pod

![ea080827c88bd8d8101b94cad9c4ead6.png][]

如果获取其他 namespace 下的pod，则报权限错误

![0aafe415b25479aded192fe27c255435.png][]

**为 pod 创建 serviceaccount**

以 metrics-server的 pod 为例，需要对 pod、node、ns 等资源进行 get list操作，因此权限配置为：

![0d07cee05e08382ef52eefa961093dc0.png][]

pod 的 yaml 配置中声明serviceAccountName为metrics-server

![2ee0252e1dedfad06996522a601abe98.png][]

以上是 user用户使用 kubeconfig、pod 使用 serviceaccount 的示例，pod 使用serviceaccount是比较好理解的，但其实 kubeconfig 也可以直接用serviceaccount来生成，不一定非得用 user，只是大多数情况下，kubeconfig 的管理是和用户的声明周期一致的，即子用户可以申领一份自己的 kubeconfig，管理员可以随时吊销或者禁用子用户 kubeconfig 的效力。这个在后面的”多租户下的kubeconfig“中会提到。

**三种机制**

谈 k8s 的认证和访问控制，一般都会看到这张图：

![78f2ab923e213429dbeb94c79ce3198a.png][]

k8s 中所有的 api 请求都要通过一个 gateway 也就是 apiserver 组件来实现，是集群唯一的访问入口。既然是 gateway，最基础的功能就是 api 的认证 + 鉴权了。对应了图上的步骤1和2，而 k8s 中还提供了第 3 步的 admission Control（准入控制），可以更方便地拦截、校验资源请求。

**三种机制：**

**1、认证：**Authentication，即身份认证。检查用户是否为合法用户，如客户端证书、密码、bootstrap tookens和JWT tokens等方式。

**2、鉴权：**Authorization，即权限判断。判断该用户是否具有该操作的权限，k8s 中支持 Node、RBAC（Role-Based Access Control）、ABAC、webhook等机制，RBAC 为主流方式

**3、准入控制**：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 等部署工具，可以跳过这一段。

**1、基础证书生成**

ca-config.json

创建用来生成 CA 文件的 JSON 配置文件，这个文件后面会被各种组件使用，包括了证书过期时间的配置，expiry字段

![d79d016c09ddc390591d71d3a6a0097f.png][]

ca-csr.json

创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件

![1eeb6cc7fbe8855ea0cd38193b5efa9d.png][]

生成基础 ca 证书

![f467df002f406dc352b4319090ba1b7b.png][]

创建自签名 CA 证书：这里只需要ca-csr.json文件，执行后会生成三个文件：

ca.csr：证书签名请求，一般用于提供给证书颁发机构，自签的就不需要了

ca.pem：证书，公共证书

ca-key.pem：CA密钥

**2、生成 apiserver 证书**

apiserver-csr.json

![1fc9f6f47f9b1ea5ced4e72c9de49f9a.png][]

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

\*\* 使用证书\*\*

![53f91d655b84a46a598f571b05bb0f7e.png][]

**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

![d01ca664e1b1ca1abda09cd81d7c3d65.png][]

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 的内容：

![7f57d500bb0340c4a9fe809db1eb41b1.png][]

除了 context，里面有三个证书字段，都是 base64 编码后的内容

certificate-authority-data: server 端的证书，用于验证 apiserver 的合法性

client-certificate-data: 客户端证书

client-key-data: 客户端私钥

可以提取出来 certificate-authority-data 的内容放到一个文件cert.txt，然后base64解码

![0e5dc88f255284a2214370bdac95b650.png][]

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 中，然后解码：

![975196c6cd6ab6c6b3f3a97651e9aeab.png][]

查看证书内容：

输出内容可以看到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

![0c193b2ea961574d12d46c16bf35f6f4.png][]

![6a7c2f9f00fe055b8a42c3a59e9df5d0.png][]

**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组

对应关系如图所示

![aa3c64878863c45ec2e07d61dbf34c8c.png][]

即 k8s 所有自身组件使用的权限都是基于内置的 clusterrole，生成出来的 kubeconfig 被各组件进程使用，权限都是默认已有 role，如果希望自己创建 role ，就要使用 rbac 授权了

至此，我们应该知道了kubeconfig 的生成流程、验证方式，以及为什么采用了 admin.conf 作为kubeconfig，kubectl就能拥有最高权限。下面是一幅示意图

![f8cf2eda14b5a7fc405c36e925f08009.png][]

**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 的鉴权机制：

![ee3135eec12337fff6e07e9968a25187.png][]

**RBAC**

RBAC（Role-Based Access Control）是 kubernetes 中基于角色的访问控制，通过自定义角色并将角色和特定的 user，group，serviceaccounts 关联起来达到权限控制的目的。

RBAC 中有三个比较重要的概念：

*  Role: 角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限；
 *  Subject: 被作用者，包括 user、group、service account，通俗来讲就是认证机制中所识别的用户；
 *  RoleBinding: 定义了“被作用者”和“角色”的绑定关系，也就是将用户以及操作权限进行绑定；

![8366ac90af4e744f19e1c3f06f455c06.png][]

RBAC 其实就是通过创建角色(Role），通过 RoleBinding 将被作用者（subject）和角色（Role）进行绑定。下图是 RBAC 中的几种绑定关系：

![19aa05f3372248397cc12f16f52c2a07.png][]

示例：

role:

![2abe45536de604973d8f73cac77d0a1f.png][]

权限声明：

![5a2e01bd89780308c7e5575968049fd0.png][]

apiGroups为“”代表所有核心资源即 v1 group

apiGroups为“\*”代表所有group

指定 pod 下的子对象如 kubectl logs xx，在resources中写为pods/log

对于 CRD 的权限可以定义为：

![47e3ea65d09ecef5c13dfaffe2d0d958.png][]

deployment、sts 等不在核心组，

![6a722d204ac6f9ff174514f0eec5164e.png][]

以 prometheus pod 所需要的权限为例：

![0ab4fe4c733c1ded4d5a2ea7ae1688ba.png][]

**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：

![ff1c66d5d7718685ad14636c7ff34582.png][]

配置：ValidatingWebhookConfiguration

![28e822a7443eace5f2faf24b66ced2a9.png][]

你需要等待几秒，然后通过通过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 年：

![218eb837867f01f1e1acb09b7da828f4.png][]

查看当前证书有效期

![c24efe5fd920d4b73e94e8969943607c.png][]

重新签发证书:续签全部证书

![e2b4d90f13a68a685bbbb23c35243841.png][]

**也可以局部进行续签**

如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证书）

![fab1ffd338bd0445a5c4aea62417662f.png][]

**方法二：使用七层正常的 http 转发**

![4b1452f84c110b2d983df9b44bf95196.png][]

**多租户集群中的的用户访问控制**

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 的最高权限

![5b7d8bbfb3a5be19a20a4d9794e0770e.png][]

tiller pod 运行在kube-system 下，拥有集群所有ns、所有资源的操作权限，不过你也可以限定tiller的使用范围，比如只能在特定的 namespace 下工作，如：

在特定 namespace 中部署 tiller，并仅限于在该 namespace 中部署资源

![e5dfa4767137ab0137987c5199468528.png][]

运行 helm init 来在 tiller-world namespace 中安装 Tiller

![c539d0ccba900e6b54f6f7dca2fd3771.png][]

而在 helm3 中已经不需要 tiller 这个组件，只需要一个 helm 二进制，因此helm 命令使用的 kubeconfig 的权限，也就决定了能够在哪个 namespace 操作什么资源，helm 权限和 kubectl 统一，更加方便。

**参考文档：**

\[1\] https://blog.tianfeiyu.com/2019/08/18/k8s\_auth\_rbac/

\[2\]https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

\[3\]https://pdf.us/2019/03/21/3061.html

\[4\]https://www.infoq.cn/article/NyjadtOXDemzPWyRCtdm

\[5\]https://www.cncf.io/wp-content/uploads/2018/07/RBAC-Online-Talk.pdf

\[6\]https://www.kubernetes.org.cn/4061.html

\[7\]https://zhangchenchen.github.io/2017/08/17/kubernetes-authentication-authorization-admission-control/

\[8\]http://dockerone.com/article/9561

\[9\]https://www.tremolosecurity.com/kubernetes-dont-use-certificates-for-authentication/

\[10\]https://help.aliyun.com/document\_detail/119596.html?spm=a2c4g.11186623.6.603.2ce12ce7vL1dsQ

\[11\]https://kubernetes.io/zh/docs/reference/access-authn-authz/node/

\[12\]https://www.youtube.com/watch?v=LgXRdfSqKj0

\[13\]https://www.youtube.com/watch?v=CnHTCTP8d48

\[14\]https://kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

\[15\]https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/

原文地址：[http://www.xuyasong.com/?p=2054\#K8S-3][http_www.xuyasong.com_p_2054_K8S-3]

END

精彩文章推荐

[k8s如何学习？搞清k8s关键技术点][k8s_k8s]

[安装kubernetes集群-灵活安装k8s各个版本高可用集群][kubernetes_-_k8s]

[Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档][Prometheus_Grafana_Alertmanager_-]

[linux架构师成长路线图：如何从月薪3千涨到月薪3万][linux_3_3]

[k8s+SpringCloud+DevOps全栈技术解读][k8s_SpringCloud_DevOps][  
][Link 1]

[Kubernetes将弃用Docker，不必恐慌][Kubernetes_Docker][  
][Link 2]

[5个维度对 Kubernetes 集群优化][5_ Kubernetes]

[Docker+k8s+DevOps企业级架构师成长路线图][Docker_k8s_DevOps]

[K8s自动扩缩容工具KEDA发布2.0版本，全面升级应用扩展能力][K8s_KEDA_2.0]

[应该监控哪些Kubernetes健康指标？][Kubernetes]

[k8s+jenkins+SonarQube+harbor构建DevOps自动化容器云平台][k8s_jenkins_SonarQube_harbor_DevOps]

[K8s 超详细总结！  
][k8s_k8s]

[如何在 Kubernetes 上扩展微服务][Kubernetes 1]

[容器运行时Containerd基础][Containerd]

## 技术交流 ##

为了大家更快速的学习知识，掌握技术，随时沟通交流问题，特组建了技术交流群，大家在群里可以分享自己的技术栈，抛出日常问题，群里会有很多大佬及时解答的，这样我们就会结识很多志同道合的人，长按或者扫描下图二维码可加我微信，备注运维或者k8s或者devops即可进群，让我们共同的努力，向着美好的未来出发吧~~~，**想要****免费获取****linux、k8s、DevOps、Openstack、Openshift、运维、开发、测试、架构师、Python、Go、面试文档、容器、岗位内推等资料也可进群获取****哈~~**

![2f1e7bf6c1a42ddd1cf7ef41aea35899.png][]

**微信：** luckylucky421302

好课推荐

《kubernetes/k8s+Jenkins+DevOps+Prometheus+微服务（istio、SpringCloud）+EFK+Ceph+Python架构师实战》专题课程链接如下：

https://edu.51cto.com/topic/4439.html

![d8761b5ea2de61d57d6ddf83e47cf343.png][]

## 微信公众号    ##

![25514e90e8e9ab0b572311c5c145df7d.png][]

点击阅读原文即可了解更多信息

![点击查看源网页][4d56055e2daff1178078c78debe0cee0.png]

[4bf73febf3d8d9dbe57c733fb9cc88a1.png]: /images/20221022/26baa46adf034dbba85612ba07931863.png
[d30233723246e5360d09bf30c977d932.png]: /images/20221022/876f55150020448c9cddbebf6ae2d197.png
[4d7f6a64d355c7d92615adef0d781b11.png]: /images/20221022/fce329dac2c44e3aa4ce0068c34a03c6.png
[81014832e2467b469f969b27a11f759f.png]: /images/20221022/89922aefb5bb47f0a0c3b0b978e5fc73.png
[ea080827c88bd8d8101b94cad9c4ead6.png]: /images/20221022/64506c8d582743369d6e60e0a8c4ed59.png
[0aafe415b25479aded192fe27c255435.png]: /images/20221022/b5c1fb9bb1ad45379d502370f6f34ef7.png
[0d07cee05e08382ef52eefa961093dc0.png]: /images/20221022/10c07b97c0614637842f8977f2c106ad.png
[2ee0252e1dedfad06996522a601abe98.png]: /images/20221022/66998073f2324dcaa0614bc288e5e0c4.png
[78f2ab923e213429dbeb94c79ce3198a.png]: /images/20221022/570901ae52844778a0a78613bd7bb8b5.png
[d79d016c09ddc390591d71d3a6a0097f.png]: /images/20221022/3aa553da7fac43aca068340eb16f4e39.png
[1eeb6cc7fbe8855ea0cd38193b5efa9d.png]: /images/20221022/165b9777ebcc46609f5609262eb8faf4.png
[f467df002f406dc352b4319090ba1b7b.png]: /images/20221022/6b461a6864ae4a86b6709780e29d2339.png
[1fc9f6f47f9b1ea5ced4e72c9de49f9a.png]: /images/20221022/b130708882df40dca49db1c5889066b5.png
[53f91d655b84a46a598f571b05bb0f7e.png]: /images/20221022/5a7b9109389e4331a62adf73c26bc6a6.png
[d01ca664e1b1ca1abda09cd81d7c3d65.png]: /images/20221022/686e5eba154c41d286c1c2e8403acc60.png
[7f57d500bb0340c4a9fe809db1eb41b1.png]: /images/20221022/ec20abcf279b473c8c06eded03624303.png
[0e5dc88f255284a2214370bdac95b650.png]: /images/20221022/146f6536e4374c43bf4bdd25af9a5730.png
[975196c6cd6ab6c6b3f3a97651e9aeab.png]: /images/20221022/3a86e208066a47b4b0e0b4c464934cf5.png
[0c193b2ea961574d12d46c16bf35f6f4.png]: /images/20221022/4a8cee2480194f728df69376e957d070.png
[6a7c2f9f00fe055b8a42c3a59e9df5d0.png]: /images/20221022/84db5b771703405394a6db4edaa155a1.png
[aa3c64878863c45ec2e07d61dbf34c8c.png]: /images/20221022/fdaf08c8af8b4bc087699ef326ff5e90.png
[f8cf2eda14b5a7fc405c36e925f08009.png]: /images/20221022/819b558bb5234b6587a2c7a6c586d824.png
[ee3135eec12337fff6e07e9968a25187.png]: /images/20221022/4c845e5314ca49239a849f8fcdd22eff.png
[8366ac90af4e744f19e1c3f06f455c06.png]: /images/20221022/fc17792873d743859ca08a5f29e06174.png
[19aa05f3372248397cc12f16f52c2a07.png]: /images/20221022/d8c77105564c4a6cb00665a80674452f.png
[2abe45536de604973d8f73cac77d0a1f.png]: /images/20221022/3ef67f1288cd4b86829e019c81fa495f.png
[5a2e01bd89780308c7e5575968049fd0.png]: /images/20221022/c5f28d94dadc450bac8321d77dfefdfe.png
[47e3ea65d09ecef5c13dfaffe2d0d958.png]: /images/20221022/889a156f27374560a7a74533efd409ef.png
[6a722d204ac6f9ff174514f0eec5164e.png]: /images/20221022/9f6f9a7bbf9c4cf0b8a7007f2766b208.png
[0ab4fe4c733c1ded4d5a2ea7ae1688ba.png]: /images/20221022/e8e55e0c44f941aca68f0e09f7272e5f.png
[ff1c66d5d7718685ad14636c7ff34582.png]: /images/20221022/8f3fb565e2d04096af674559ab21f908.png
[28e822a7443eace5f2faf24b66ced2a9.png]: /images/20221022/05c7cd2f7ab4491e91b541956aa4a1f9.png
[218eb837867f01f1e1acb09b7da828f4.png]: /images/20221022/92a63b30c78546509ddd566eaf1bba72.png
[c24efe5fd920d4b73e94e8969943607c.png]: /images/20221022/0e97935898a349989ac0cf0e8fc6e689.png
[e2b4d90f13a68a685bbbb23c35243841.png]: /images/20221022/4ac69fd686bc4e90a31d72a8d135097e.png
[fab1ffd338bd0445a5c4aea62417662f.png]: /images/20221022/ae156380b7554f1c92857705eae00cee.png
[4b1452f84c110b2d983df9b44bf95196.png]: /images/20221022/ada57eddde1b4a2491b0d44f55ec4379.png
[5b7d8bbfb3a5be19a20a4d9794e0770e.png]: /images/20221022/71f8c6c00f5f487dbf16e689300e3dbc.png
[e5dfa4767137ab0137987c5199468528.png]: /images/20221022/ab957aba62594785abafa72afd269f97.png
[c539d0ccba900e6b54f6f7dca2fd3771.png]: /images/20221022/d6ba1b65bf1a4262b9b647b8f04cdb6a.png
[http_www.xuyasong.com_p_2054_K8S-3]: https://mp.weixin.qq.com/s?__biz=MzIzNTU1MjIxMQ%3D%3D&idx=1&mid=2247483997&scene=21&sn=4c2c6f2ffdf490ee9fc401161724983e#wechat_redirect
[k8s_k8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639ba0cc1412b6c2e6d7c057dceaf125787fe4a0a0e12caf94b7bb3796296dbb3a278c36fe&idx=1&mid=2247488693&scene=21&sn=5ad25ab1809828acfa7e75dcfb824542#wechat_redirect
[kubernetes_-_k8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6384b8cc140dae0e6efba75100e29549cc440a010a5c7976bdd313e9c6139569b197e20a8f&idx=1&mid=2247486381&scene=21&sn=f07ae730cdc3ca2442462e0c7f2caed1#wechat_redirect
[Prometheus_Grafana_Alertmanager_-]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb638b08cc14021e5e025f2f0b89d18ec5ef19f9dec4429a56f356e8b596d01095e313dab3e3&idx=1&mid=2247484445&scene=21&sn=bf8928e7aae815b8e7f9ac56a67289ce#wechat_redirect
[linux_3_3]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639e28cc14173e61b92f64bcd416338ee89c60c2a6009cb1259a79476bc861646505c8094c&idx=1&mid=2247487805&scene=21&sn=4ff2737a8ba870626f266e9520096a55#wechat_redirect
[k8s_SpringCloud_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639deecc1414f8b640079ff0c4ca4845eeb0d240d120db552e3a8c81f452abd7b9a0612879&idx=1&mid=2247488251&scene=21&sn=1878931872ee9d6f03cd6ec541bcdf2a#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f9bcc14168dbffbc995646942ed75995d1181296af73df1cd13b6d3f0052d42934648cc&idx=1&mid=2247487630&scene=21&sn=d4cbb1afb6d2d059c0e9d319dd47fdf0#wechat_redirect
[Kubernetes_Docker]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f68cc14167e344cea74d031c8f466e51cb00f19d112d07aeb73fa062a7be5b473d055d7&idx=1&mid=2247487613&scene=21&sn=61308d2c58562ad51ad8c1327a2353e1#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f7acc14166ca2176a440bbcde9d563c78df76bff8a5a8e0cff467f23dfc9415b2c5c4ef&idx=1&mid=2247487599&scene=21&sn=8f107a8d869238058e50e8cd73175c5a#wechat_redirect
[5_ Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6383aecc140ab8050df002d52f6063e85ad2777f4ec0941c9d40ea49c50c11f23542f43dfc&idx=1&mid=2247486651&scene=21&sn=2fe1be9d4a335077757c46a36cb1aea2#wechat_redirect
[Docker_k8s_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639ed5cc1417c3f90de67376a354d0c7f1d918151f3bcfe301e319d79c2cfee71fec24017f&idx=1&mid=2247487936&scene=21&sn=141bcb9b8346826458f83693bc6b6bb1#wechat_redirect
[K8s_KEDA_2.0]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639d51cc141447eb0ded990df4abe27860fc66b782875f3e656bcdfe5a7b00b2bfb76b9d15&idx=1&mid=2247488068&scene=21&sn=f24c1e2561160fe5feb9a17c6bcc8d1c#wechat_redirect
[Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639dc8cc1414de4ad7398463fb0a5bbb414e1444a0f4b6d3bb8e922697a1d7b3db6130b650&idx=1&mid=2247488221&scene=21&sn=b7cc4fe1347303ba87f226f24b5985ab#wechat_redirect
[k8s_jenkins_SonarQube_harbor_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639c31cc1415277a4203065c3aaa468949e48dc8c75d65026c59584b0517cef18e26273373&idx=1&mid=2247488292&scene=21&sn=d81030fed2368e707ee984929b2ee6a5#wechat_redirect
[Kubernetes 1]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639b80cc141296252512e6456dbdcd4d19629630bff9ae07a0aada93029e87dc359d754f46&idx=1&mid=2247488661&scene=21&sn=2e55fb79ddef40022ff4beb642361c95#wechat_redirect
[Containerd]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639b5ecc141248b6378ace908c840a942257e4790b2b91254ca519ff1cfb13e2924a41d8db&idx=1&mid=2247488587&scene=21&sn=e111dff943411a657b5e9106e73f9dfe#wechat_redirect
[2f1e7bf6c1a42ddd1cf7ef41aea35899.png]: /images/20221022/b5fbd34286894a80b227b15e0a044fe4.png
[d8761b5ea2de61d57d6ddf83e47cf343.png]: /images/20221022/26889c2d39534c7e8249c228f1360da5.png
[25514e90e8e9ab0b572311c5c145df7d.png]: /images/20221022/0d6683b4f2794cc3afd55c8fd4430032.png
[4d56055e2daff1178078c78debe0cee0.png]: /images/20221022/ce279854142d4aaea020ee7265e096b1.png