关于cncf:使用RBAC-Impersonation简化Kubernetes资源访问控制

客座文章最后由 Juanjo Ciarlante 在 Bitnami 上发表

介绍

Kubernetes，像任何其余平安零碎一样，反对以下概念：

身份验证（Authentication）：验证和证实用户、组和服务帐户的身份
受权（Authorization）：容许用户应用 Kubernetes 资源执行特定的操作
会计（Accounting）：存储主题操作，通常用于审计（auditing）目标

受权 – 解决用户对资源拜访的过程 – 总是一个挑战，特地是当拜访由团队成员身份或我的项目成员身份管制时。两个要害挑战是：

因为 Kubernetes 组（group）成员关系是由身份提供程序（Identity Provider，IdP）从内部解决到 API 自身的，因而集群管理员须要与身份提供程序管理员交互来设置这些组成员关系，这使得工作流可能很麻烦。身份提供者可能基本不提供组成员关系，从而迫使集群管理员按用户解决拜访，即 Kubernetes RoleBindings 蕴含容许最终用户（end-user）的“残缺”列表。

在本教程中，咱们提出了一种应用现有 Kubernetes 受权个性“表演”组成员身份的办法 – 能够通过团队、我的项目或你可能须要的任何其余聚合。

假如和前提条件

本文假如你：

理解个别的最终用户平安概念
有一些对于 RBAC 角色和绑定的常识和教训
了解身份验证和受权之间的区别
配置集群时启用 Kubernetes RBAC，自 1.6 发行版以来默认设置

Kubernetes 身份验证概述

身份验证是任何集群管理员都应该遵循的策略的要害局部，以爱护 Kubernetes 集群基础设施，并确保只有被容许的用户能力拜访它。

上面简要介绍一下 Kubernetes 如何进行身份验证。次要有两类用户：

ServiceAccounts（SAs）：
- ID 由 Kubernetes 自身在集群内治理。
- 每个 ServiceAccount 都有一个身份验证令牌（JWT），作为它的凭据
用户（内部角色或机器人用户）：
- ID 是内部提供的，通常由 IdP 提供。有许多机制能够提供这个 ID，例如：

    *   x509 证书

    *   动态令牌或用户 / 密码文件

    *   通过内部身份提供者（IdP）的 OpenID 连贯令牌（OpenID Connect Tokens，OIDC）*   Webhook 令牌

    *   托管的 Kubernetes 提供商（例如 GKE, AKS, EKS）与他们本人的云认证机制集成

用户 ID 蕴含在对 Kubernetes API 的每次调用中，而该 API 又是由访问控制机制受权的。

采纳 OIDC 进行身份验证很常见，因为它提供了单点登录（Single-Sign-On，SSO）体验，不过有些组织可能依然应用最终用户 x509 证书，因为无需任何内部 IdP 干涉就能够颁发这些证书。然而，这些独特的办法带来了以下挑战：

x509 证书：只管它们很容易设置，但用户最终领有一个无奈吊销的 x509 包（密钥和证书）。这迫使集群所有者指定较短的过期工夫，这显然取决于人员流动性。此外，用户的组被写入 x509 证书自身。这迫使集群管理员在用户每次更改成员资格时都从新颁发证书，同时无奈吊销以前的证书（即，用户将持续放弃旧组的成员身份，直到以前的证书过期）。
OIDC 身份验证：应用组织应用的 IdP 提供 SSO 很不便。当提供的身份短少组成员关系，或者组成员关系（由组织设置）不能间接映射到用户的 Kubernetes 工作负载需要的团队或我的项目成员关系时，就会呈现问题。

用户当初曾经通过身份验证，咱们须要看看如何受权他们应用 Kubernetes 集群。

Kubernetes 受权和 RBAC 概述

在网上有许多对于 Kubernetes RBAC 的资源。如果你不齐全相熟这些概念，我举荐这个对于在 Kubernetes 中揭开 RBAC 神秘面纱的很棒的教程。要理解对于如何在集群中配置 RBAC 的更多信息，请参阅本教程。Kubernetes RBAC 容许指定：

A）容许的 SUBJECTS，对 B）资源品种进行 VERBS（能够抉择放大到特定的资源名称）

在下面的模型中，B）被实现为一个 Kubernetes Role（或 ClusterRole），而 A）-> B）的绑定被建模为一个 Kubernetes RoleBinding（或 ClusterRoleBinding），如下图所示：

应用表演的（impersonated）“虚构用户”来管制拜访

Kubernetes RBAC 蕴含一个非凡的 impersonate（表演）动词，可用于容许 Subjects（即 Users、Groups、ServiceAccounts）取得其余 Kubernetes 用户或组身份。

因为这些取得的身份不肯定须要存在 – 还记得 Kubernetes 管制立体自身没有用户或组存储 – 咱们将在本文中将它们称为“虚构用户（virtual-users）”。此个性容许将“虚构用户”设置为“角色帐户”平安主体。例如：

alice@example.com，作为利用前端（app-fe）团队的成员，能够表演虚构用户 app-fe-user

bob@example.com，作为应用程序后端（app-be）团队的成员，能够表演虚构用户 app-be-user

能够创立 RBAC 规定来容许这些“虚构用户”拜访他们须要的 Kubernetes 资源，如下图所示：

如上所示，利用现有的 Kubernetes RBAC 个性，受权解决分为：

团队成员：RBAC ClusterRoles 和 ClusterroleBindings，它们示意容许用户表演其团队的虚构用户。
团队职责：RBAC 角色和角色绑定，阐明团队的虚构用户能够拜访哪些理论的 Kubernetes 资源。

理论的表演操作是通过在 Kubernetes API 调用的头文件指定的，这是不便的由 kubectl 通过：

kubectl --as <user-to-impersonate> ...
kubectl --as <user-to-impersonate> --as-group <group-to-impersonate> ...

提醒：没有 -as 参数的 kubectl -as -group…是有效的。为了简化 CLI 的应用，本文倡议应用下面的第一种模式，通过将用户表演为示意用户组或团队成员的“虚构用户”进行建模。

如下图所示的例子，用户“alice@example.com”能够通过重载 kubectl CLI 应用上面的命令轻松表演虚构团队用户“app-fe-user”：

kubectl --as app-fe-user ...

应用 RBAC 规定的工作示例

当初曾经“创立”了虚构用户，让咱们看看 RBAC 规定在实践中的一个工作示例。对于这个用例，假如以下场景：

用户 alice@example.com 和 alanis@example.com 曾经通过某种模式的 SSO 认证（例如 OIDC 连接器到谷歌 IdP）。
他们是 app-fe（即利用前端）团队的成员。
Kubernetes 集群有三个与 app-fe 工作负载相干的命名空间：开发（development）、登台（staging）和生产（production）。
将创立一个名为 app-fe-user 的虚构用户，容许 Alice 和 Alanis 表演它。
app-fe 用户将被授予以下拜访权限：
dev-app-fe NS：齐全治理
staging-app-fe NS：编辑拜访
prod-app-fe NS：仅查看拜访

提醒：为了简略起见，咱们将应用现有的 Kubernetes ClusterRoles（可用于命名空间作用域的角色绑定）来实现上述拜访规定。

步骤 1：筹备 RBAC 清单

上面的例子应用 k14s/ytt 作为模板语言实现了这个想法（你能够找到上面的 ytt 源代码和生成的 YAML）：

#@ load("impersonate.lib.yml",
#@      "ImpersonateCRBinding", "ImpersonateCRole", "RoleBinding"
#@ )
https://github.com/k14s/ytt
#@ members = ["alice@example.com", "alanis@example.com"]
#@ prod_namespace = "prod-app-fe"
#@ stag_namespace = "staging-app-fe"
#@ dev_namespace = "dev-app-fe"
#@ team_user = "app-fe-user"
#! Add impersonation bindings <members> -> team_user
--- #@ ImpersonateCRBinding(team_user, members)
--- #@ ImpersonateCRole(team_user)
#! Allow *team_user* virtual-user respective access to below namespaces
--- #@ RoleBinding(team_user, prod_namespace, "view")
--- #@ RoleBinding(team_user, stag_namespace, "edit")
--- #@ RoleBinding(team_user, dev_namespace, "admin")

失去的 YAML 输入能够通过 kubectl 进行推送，像平常一样执行以下命令：

$ ytt -f . | kubectl apply -f-  [--dry-run=client]

用户身份（本例中为“alice@example.com”）能够由本文结尾探讨的任何身份验证机制提供。

步骤 2：测试

在将 RBAC 资源推到集群之后，alice@example 能够应用 kubectl auth can-i…命令来验证设置。例如：

$ kubectl auth can-i delete pod -n dev-app-fe
no
$ kubectl --as app-fe-user auth can-i delete pod -n dev-app-fe
yes
$ kubectl --as foo-user auth can-i get pod
Error from server (Forbidden): users "foo-user" is forbidden: User "alice@example.com" cannot impersonate resource "users" in API group "" at the cluster scope

这齐全是为 Kubernetes 的 sudo 的感觉，不是吗？

步骤 3：将表演设置保留到 Kubernetes 配置文件中

为了事后设置表演的配置，能够在用户的 KUBECONFIG 文件的“user:”条目中增加一些没有宽泛文档化的字段：

- name: alice@example.com@CLUSTER
 user:
 as: app-fe-user
 auth-provider:
 config:
 client-id: <...>.apps.googleusercontent.com
 client-secret: <...>
 id-token: <... JWT ...>
 idp-issuer-url: https://accounts.google.com
 refresh-token: 1//<...>
 name: oidc

这个长久的设置是有用的，因为它防止了须要：

在每次调用时向 kubectl 提供 -as…参数
须要其余的 Kubernetes 工具来反对表演，例如 helm 就是一个显著的短少这个个性的例子

审计跟踪

Kubernetes 表演在审计跟踪方面设计得很好，因为 API 调用应用残缺的原始身份（user）和表演用户（impersonatedUser）进行日志记录。上面的代码片段显示了一个 kube-audit 日志跟踪条目，它是由 kubectl –as app-fe-user get pod -n dev-app-fe 触发的：

{
 "kind": "Event",
 "apiVersion": "audit.k8s.io/v1",
 "level": "Request",
 "auditID": "032beea1-8a58-434e-acc0-1d3a0a98b108",
 "stage": "ResponseComplete",
 "requestURI": "/api/v1/namespaces/dev-app-fe/pods?limit=500",
 "verb": "list",
 "user": {
 "username": "alice@example.com",
 "groups": ["system:authenticated"]
 },
 "impersonatedUser": {
 "username": "app-fe-user",
 "groups": ["system:authenticated"]
 },
 "sourceIPs": ["10.x.x.x"],
 "userAgent": "kubectl/v1.18.6 (linux/amd64) kubernetes/dff82dc",
 "objectRef": {
 "resource": "pods",
 "namespace": "dev-app-fe",
 "apiVersion": "v1"
 },
 "responseStatus": {"metadata": {},
 "code": 200
 },
 "requestReceivedTimestamp": "2020-07-24T21:25:50.156032Z",
 "stageTimestamp": "2020-07-24T21:25:50.161565Z",
 "annotations": {
 "authorization.k8s.io/decision": "allow",
 "authorization.k8s.io/reason": "RBAC: allowed by RoleBinding"rb-app-fe-user-admin"of ClusterRole"admin"to User"app-fe-user""
 }
}

挑剔的读者还会留神到，下面的“user”字段只有与用户身份相干的“username”，因为“system：authenticated”显然是一个通用的组值。

总结

通过现有的 Kubernetes RBAC 个性，集群管理员能够创立由角色用户表演的虚构用户平安主体，以建模“角色帐户”受权计划。这种办法提供了与 Kubernetes 平安配置相干的许多益处，如下所示：

它要求认证机制只提供用户身份数据（即不须要组）。
它容许 Kubernetes 集群管理员应用现有的 Kubernetes RBAC 表演个性构建团队成员模式。
它容许 Kubernetes 集群管理员创立 RBAC 规定来针对这些表演的“虚构用户”拜访 Kubernetes 资源（Kubernetes Rolebinding“subjects”，通常只有一个条目）。
它将成员关系从理论的资源拜访规定中解耦，从而容许创立更清晰的 RBAC 条目。这样的条目更容易保护和审计，缩小了集群管理员的复杂性和工作负载。
它有利于组织，因为集群管理员能够更准确地实现团队和我的项目管制，加重员工的上岗 / 下岗以及相干的平安方面。

有用的链接

https://en.wikipedia.org/wiki…
https://kubernetes.io/docs/re…
https://kubernetes.io/docs/re…
https://kubernetes.io/docs/re…
https://get-ytt.io/

点击浏览网站原文。

CNCF (Cloud Native Computing Foundation)成立于 2015 年 12 月，隶属于 Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。

关于cncf:使用RBAC-Impersonation简化Kubernetes资源访问控制

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）