权限模型之基于角色的访问控制(RBAC)

前言

在搞明白 RBAC 这个访问控制模型之前,我们得先了解下,信息安全中的一些基本的概念,从而了解 RBAC 属于哪一个环节。

  • 认证(Authentication):系统识别操作用户的真实身份,也就是弄清楚操作用户到底是谁。
  • 授权( Authorization):系统控制一个用户操作数据的权限,也就是控制操作用户在系统中能干什么。
  • 凭证(Credential):系统承载和用户的认证授权信息,你需要一个凭证,来证明你就是你,然后就可以干允许你干的事了。
  • 机密(Confidentiality):系统确保凭证或数据传递与存储的隐秘性,避免被篡改或者泄露。
  • 传输(Transport Security):确保系统和用户之间的网络传输信息无法被第三方窃听、篡改。
  • 验证(Verification):系统确保提交到每项服务中的数据是合乎规则的,乱填一些数据,是可能导致系统安全问题的。

那么 RBAC 是解决什么问题的呢?也就是“(User)拥有什么权限(Authority)去操作(Operation)哪些资源(Resource)”,所以本质上属于一种授权(访问控制)行为。

RBAC

什么是 RBAC?

基于角色的访问控制(Role-based access control,简称 RBAC),指的是通过用户的角色(Role)授权其相关权限,这实现了更灵活的访问控制,相比直接授予用户权限,要更加简单、高效、可扩展。

怎么理解 RBAC?

这里我画了一张图,图中的贝丝是管理员,所以他具备了对资源 A 和资源 B 的可读、可写资源。而莫斯作为开发者,他对资源 A 具有可读、可写权限,但是对资源 B 只有可读权限。这样我们就满足了“(User)拥有什么权限(Authority)去操作(Operation)哪些资源(Resource)”的行为。但是显然有个不好的地方,让我们接着往下说。

这时来了一个新的开发人员塔斯,想加入我们一起开发,由于他的职责和莫斯是一样的,所以我们给他分配了同样的权限。细心的你可能已经发现了,给莫斯和塔斯分配权限是一个重复的步骤,看上去并没有什么不妥。

那么我们要想象一种糟糕的场景,如果我们需要对开发人员分配许多的权限,而且开发人员同时又有很多该怎么办?想必贝丝管理员这时一定在抱怨了!🥲如果我们这时要删除所有开发人员对资源 A 的可写权限,也需要一个个更改,这简直坏透了🤬

这时我们可以考虑用一种通用配置的思路,而不是直接给用户分配这些权限。如图所示,我们只需要给贝丝分配 admin 配置,给莫斯和塔斯分配 dev 配置即可。如果下次再有小伙伴要参与进来,直接分配给他 dev 配置就可以了。

我们在系统中通常把这些配置文件叫做“角色”,这也就是基于角色的访问控制的方式,还是很好理解的,对吧?

软件开发中的 RBAC

在软件开发中,普遍采用的 RBAC 模型,是 NIST RBAC 模型。咱们上面说的,为了避免对每一个用户单独设置权限,以及避免过程中容易产生的错误,将权限从直接绑定用户,改为了绑定“角色”。将权限控制变为了对“角色拥有操作哪些资源许可”。

这里的“许可”可以理解为抽象权限的具象化体现,角色解耦了用户和权限之间的多对多关系,而许可是用来解耦操作和资源之间的多对多关系的。比如对资源 A 可以有增、删、改、查等操作。

注:1996年,莱威·桑度(Ravi Sandhu)等人在前人的理论基础上,提出以角色为基础的访问控制模型,故该模型又被称为RBAC96。之后,美国国家标准局重新定义了以角色为基础的访问控制模型,并将之纳为一种标准,称之为NIST RBAC。

在软件开发中,如果要实现 RBAC 模型,则需要实现它的几个核心概念:

  • 用户:访问系统的任意用户。
  • 角色:角色是一个逻辑集合,你可以授权一个角色某些操作权限,然后将角色授予给用户,被授予角色的用户将会继承这个角色中的所有权限。
  • 资源:应用系统中的实体对象一般定义为资源,比如订单、商品、文档等等,而每种资源都可以定义多个操作,比如商品有查看、编辑、上架、删除操作;
  • 授权:把某类(个)资源的某些(个)操作授权给角色或者用户。

注意“授权”这一项,我给“或者”加粗了,为什么这里用“或者”呢。因为有些软件开发框架在设计时,并没有完全遵循 RBAC 来设计,比如 Spring Security...不过并不是说这样设计不好,首先怎么用是用户自己的事,可以完全遵守 RBAC 来用,而 Authority 在某些场景下,它也是适用的。

操作系统中的 RBAC

在 Linux/Unix 系统中,RBAC 用于控制用户对通常仅限于超级用户的任务的访问。通过对进程和用户应用安全属性,RBAC 可以向多个管理员分派超级用户功能。进程权限管理通过特权实现。用户权限管理通过 RBAC 实现。

我们都知道,root 用户在 Linux 系统中,是具有最高权限的,是基于叫做超级用户模型的(管理员对系统要么具有全部控制权要么毫无控制权)。而使用 RBAC,可以在更精细的级别上强制执行安全策略。RBAC 采用最小特权的安全原则。最小特权表示用户仅具有执行某项作业所必需的特权。普通用户具有足够特权来使用其应用程序、检查其作业状态、打印文件、创建新文件等。超出普通用户功能以外的功能将分组到各权限配置文件中。如果用户将要执行的作业要求具有某些超级用户功能才能执行,这些用户将承担拥有适当权限配置文件的角色。

RBAC 会将超级用户功能收集到权限配置文件中。这些权限配置文件将指定给称为角色的特殊用户帐户。然后,用户可以承担某个角色,以执行要求具有某些超级用户功能才能执行的作业。

参考资料: RedHat 基于角色的访问控制 (RBAC)

Kubernetes 中的 RBAC

在 Kubernetes 中,我们通常授予对 API 端点(endpoints)的访问权限。RBAC 通过允许或禁止访问管理 API 资源来定义用户、组和进程的策略。

在 Kubernetes 中,可以用 RBAC 做哪些操作呢?比如:

  • 为系统的不同用户,定义不同的角色,来访问不同的 Kubernetes 资源。
  • 控制 Pod 中运行的进程,以及可以通过 Kubernetes API 执行的操作。
  • 限制命名空间的资源可见性等等。

在 Kubernetes 中,RBAC 由三个模块组成,它们一起将 API 原语(API primitives)及其允许的操作连接到用户、组或者 ServiceAccount.

Kubernetes RBAC API

我们来了解下实现 RBAC 功能的 Kubernetes API 原语:

  • 角色:角色 API 原语声明了该规则可以操作的 API 资源及其操作(查看、删除等)。
    • 允许查看和删除 Pods
    • 允许查看 Pods 的日志
  • RoleBinding:RoleBinding API 原语将角色绑定到主题。例如:将允许更新服务的角色绑定到用户 贝丝。

所有的 Kubernetes 集群都有两类用户:Kubernetes 管理的 Service Account 和普通用户。角色可以分配给外部用户或机器人(集群内的应用程序)。我们来总结一下,完成访问控制的行为,需要的几步操作:

  • 创建/拥有一个用户。
  • 创建角色以向 API 端点授予权限。
  • 将角色链接到用户。

最后一步称为绑定,由上图中名为 RoleBinding 的对象完成,该对象将身份链接到角色。

注:Roles 和 RoleBindings 在命名空间中创建,它们授予对当前命名空间中资源的访问权限。如果需要将角色定义为全局而不是限定为命名空间,需要 ClusterRole,要将身份链接到全局角色,需要使用 ClusterRoleBinding

最后

RBAC 访问控制模型,应该是开发中比较常见的模型了,我采取图文的形式,结合自己的理解,写下了这篇文字,希望能对看到的小伙伴提供帮助!😊

我的水平和认知都是有限的,如果你想了解更多关于 RBAC 或者访问控制模型的知识,我为你准备了一些参考资料链接: AWS 的访问控制模型 Wiki-基于角色的访问控制 Kubernetes 使用 RBAC 鉴权 基于角色的访问权限控制 (RBAC) 概览 Azure 的访问控制模型

updatedupdated2022-12-012022-12-01