本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前篇文章透过 rke / helm 成功的搭建了一个 Rancher 服务，并且於第一次登入时按照系统要求创建了一组给 admin 使用的密码，并且使用该 admin 的帐号观察到了第一组创建被 Rancher 管理的 Kubernetes 丛集。

复习: 该 K8s 丛集并不是 Rancher 创造的，而是我们事先透过 rke 创造用来部署 Rancher 服务的 k8s 丛集。

对於 IT 管理人员来说，看到一个新的服务通常脑中会闪过的就是该服务的使用者管理权限该怎麽处理? 最直观也简单的方式就是透过该服务创建众多的本地使用者，每个使用者给予不同的权限与帐号密码。但是这种使用方式实务上会有太多问题

1. 团队内员工通常不喜欢每一个服务都有独立的密码，最好能够用一套密码去存取公司内所有服务
2. 员工数量过多时，通常团队也很懒得帮每个员工都独立创造一份帐号密码，更常发生的事情是一套帐号密码多人共同使用。
3. 多人共同使用的问题就是会丧失了稽核性，没有办法知道是谁於什麽时间点进行什麽操作，未来要除错与找问题时非常困难
4. 如果权限还想要用群组来管理时，整个要处理的事情就变得又多又复杂
5. 由於帐号密码都是服务本地管理，这意味团队内的帐号密码是分散式的架构，因此有人想要改密码就需要到所有系统去改密码，这部分也是非常不人性化，特别如果员工离职时，要是有服务忘了删除可能会造成离职员工还有能力去存取公司服务。

因此大部分的 IT 都不喜欢使用本地帐号，更喜欢使用混合模式来达到灵活的权限管理。

1. 服务想办法整合外部的帐号密码系统，常见的如 Windows AD, LDAP, GSuite, SMAL, OpenID, Crowd 等。
2. 每个服务都维持一个本地使用者，该使用者是管理员的身份，作为一个紧急备案，当外部帐号密码系统出问题导致不能使用时，就必须要用本地使用者来存取。

混合模式的架构下，所有员工的帐号与密码都采用集中式管理，任何第三方服务都要与该帐号系统整合，因此

1. 员工只需要维护一套帐号密码即可登入团队内所有服务，如果员工需要改密码，也只需要改一个地方即可
2. IT 人员可以统一管理群组，每个第三方服务针对群组去进行权限控管即可。
3. 这种架构下不会有共享帐号密码的问题，每个使用者登入任何系统都会有相关的日志，未来除错也方便

因此本篇文章就来探讨 Rancher 提供何种使用者登入与权限控管，系统管理员架设维护时可以如何友善的去设定 Rancher

Authorization 授权

Rancher 的世界中将权限分成三大块，由大到小分别是

1. Global Permission
2. Cluster Role
3. Project Role

其中 Cluster/Project 这个概念要到後面章节探讨如何用 Rancher 去架设与管理 Kubernetes 丛集时才会提到，因此这边先专注於第一项，也就是 Global Permission。

Global Permission 代表的是 Rancher 服务本身的权限，本身跟任何 Kubernetes 丛集则是没有关系。
Rancher 本身采用 RBAC (Role-Based Access Control) 的概念来控制使用者的权限，每个使用者会依据其使用者名称或是所属的群组被对应到不同Role。

Global Permission 预设提供多种身份，每个身份都有不同的权限，以下图来看(Security->Roles)

图中是预设的不同 Role，每个 Role 都有各自的权限，同时还可以去设定说当一个新的外部使用者登入时，应该要赋予何种 Role
权限部分是采取叠加状态的，因此设计 Role 的时候都是以 "该 Role 可以针对什麽 API 执行什麽指令"，没有描述到的就预设当作不允许。
因此 Role 是可以互相叠加来达到更为弹性的状态，当然预设 Role 也可以有多个。

注: 本图片并不是最原始的 Rancher 设定，预设状态有被我修改过，请以自己的环境为主。

Role 这麽多种对於初次接触 Kubernetes 与 Rancher 的管理员来说实在太复杂与太困难，因此 Rancher 又针对这些 Role 提供了四种好记的名称，任何使用者与群组都可以基於这四种 Role 为基础去添加不同的 Role 来达到灵活权限。

这四种好记的 Role 分别为

1. Administration
   超级管理员，基本上什麽都可以操作，第一次登入时所使用的 admin 帐号就属於这个权限

2. Restricted Admin
   能力近乎於超级管理员，唯一不能管理的就是 Rancher 本身所在的 kubernetes 丛集，也就是前篇文章看到的 local 丛集。

3. Standard User: 可以透过 Rancher 创建 Kubernetes 丛集 并且使用的使用者，大部分情况下可以让非管理员角色获得这个权限，不过因为创建过多的 Kubernetes 丛集有可能会造成成本提高，所以赋予权限时也要注意到底什麽样的人可以拥有创造 kubernetes 丛集的权限。

4. User-Base: 基本上就是一个 read-only 的使用者，同时因为本身权限很低，能够看到的资讯非常少，更精准的来说就是一个只能登入的使用者。

Authentication 认证

前述探讨如何分配权限，接下来要探讨的就是要如何帮使用者进行帐号密码的验证，这部分 Rancher 除了本地使用者之外也支援了各式各样的第三方服务，譬如

1. Microsoft Active Directory
2. GitHub
3. Microsoft Azure AD
4. FreeIPA
5. OpenLDAP
6. Microsoft AD FS
7. PingIdentity
8. Keycloak
9. Okta
10. Google OAuth
11. Shibboleth

Rancher v2.6 的其中一个目标就是支援基於 OIDC 的 Keycloak ，因此如果团队使用的是基於 OIDC 的 Keycloak 服务，读者不仿可以期待一下 v2.6 的新功能。

使用者可以於 security->authentication 页面看到如下的设定页面

官方网站中有针对上述每个类别都提供一份详细的教学文件，要注意的是因为 Rancher 版本过多，所以网页本身的内容有可能你会找到的是旧的版本，因此阅读网页时请确保你当前看到的版本设定方式与你使用的版本一致。

预设情况下，管理者只能针对一个外部的服务进行认证转移，不过这只是因为 UI 本身的设定与操作限制，如果今天想要导入多套机制的话是可以从 Rancher API 方面去进行设定，对於这功能有需求的可以参考这个 Github Issue Feature Request - enabling multiple authentication methods simultaneously #24323

实战演练

上述探讨完了关於 Rancher 基本的权限管理机制後，接下来我们就来实际试试看到底用起来的感觉如何。
由於整个机器都是使用 Azure 来架设的，因此第三方服务我就选择了 Azure AD 作为背後的使用者权限，之後的系列文章也都会基於这个设定去控制不同的使用者权限。

下图是一个想要达到的设定状况

Rancher 本身拥有一开始设定的本地使用者之外，还要可以跟 Azure AD 衔接
而 Azure AD 中所有使用者都会分为三个群组，分别是

1. IT
2. QA
3. DEV

我希望 IT 群组的使用者可以获得 Admin 的权限，也就是所谓整个 Rancher 的管理员。
而 QA/DEV 目前都先暂时给予一个 User-Base 的权限，也就是只能单纯登入然後实际上什麽都不能做。
这两个群组必须要等到後面探讨如何让 Rancher 创建丛集时才会再度给予不同的权限，因此本篇文章先专注於 Rancher 与 AD 的整合。

本篇文章不会探讨 Azure AD 的使用方式与概念，因此我已经於我的环境中创建了相关的使用者以及相关的群组。

整合方面分成两大部分处理

1. Azure AD 与 Rancher 的整合
2. Rancher 内的 Roles 设定

Azure AD 的部分可以参考官方教学，里面有非常详细的步骤告知要如何去 Azure 内设定，这边要特别注意就是千万不要看错版本，以及最後填写 Azure Endpoints 资讯时版本不要写错。

下图是 Rancher 内的设定，其中 Endpoints 部分要特别小心

1. Graph 要使用 https://graph.windows.net/ 而不是使用 Azure UI 内显示的 https://graph.microsoft.com
2. Token/Authorization 这两个要注意使用的是 OAUTH 2.0 (V1) 而不是 V2

下图是 Azure 方面的设定，所以使用时要使用 V1 的节点而不是 V2，否则整合时候会遇到各种 invalid version 的 internal error.

当这一切整合完毕後重新登入到 Rancher 的画面，应该要可以看到如下图的画面

画面中告知 Rancher 的登入这时候分成两种方式，分别是透过 Azure AD 以及使用本地使用者登入。

权限控制

当与 Azure AD 整合完毕後，首先要先透过本地使用者进行权限设定，因为本地使用者本身也是 Admin 的关系，因此可以轻松地去修改 Rancher。

如同前面所提，希望整体权限可以是

1. IT 群组的人为超级使用者
2. DEV/QA 群组的人为只能登入的使用者 (User-Base)。

同时这边也要注意，因为 Rancher 的使用者与群组两个权限是可以分别设定且叠加的，因此设定的时候必须要这样执行

1. 将所有第一次登入的外部使用者的预设使用者都改为 (User-Base)
2. 撰写群组的相关规则，针对 IT/DEV/QA 进行处理。

预设情况下， Rancher 会让所有第一次登入的使用者都给予 Standard-User 的权限，也就是能够创建 k8s 丛集，这部分与我们的需求不同。

所以第一步骤，移动到 security->roles 里面去修改预设使用者身份，取消 User 并且增加 User-Base

第二步骤则是移动到 security-groups 内去针对不同 Group 进行设定

针对 IT 群组，给予 Administrator 的权限

针对 Dev 群组给予 User-Base 的权限

最後看起来会如下

到这边为止，我们做了两件事情

1. 所有新登入的使用者都会被赋予 User-Base 的权限
2. 当使用者登入时，会针对其群组添加不同权限
   如果是 IT，则会添加 Administrator 的权限，因此 IT 群组内的人就会拥有 User-Base + Administrator 的权限
   如果是 DEV/QA 的群组，则会添加 Base-User 的权限，因此该群组内的人就会拥有 User-Base + User-Base 的权限，基本上还是 User-Base。

设定完毕後就可以到登入页面使用事先创立好的使用者来登入。

当使用 Dev 群组的使用者登入时，没有办法看到任何 Cluster

相反的如果使用 IT 群组的使用者登入时，则因为属於 Administrator 的权限，因此可以看到系统上的 RKE 丛集。

本篇文章探讨了基本权限控管的概念并且展示了使用 Azure AD 後的使用范例，一旦了解基础知识後，接下来就是好好研究 Rancher 内有哪些功能会使用到，哪些不会，针对这部分权限去进行设定，如果系统预设的 Role 觉得不够好用时，可以自行创立不同的 Roles 来符合自己的需求，并且使用使用者与群组的概念来达到灵活的设定。

下篇文章将会使用 IT 的角色来看看到底 Rancher 上还有什麽设定是横跨所有 Kubernetes 丛集，以及这些设定又能够对整个系统带来什麽样的好处。