客座文章最后由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-feno$ kubectl --as app-fe-user auth can-i delete pod -n dev-app-feyes$ kubectl --as foo-user auth can-i get podError 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微信公众号。