Kubernetes RBAC工作原理 - Daniele


但是,让我们先把RBAC放在一边,看看我们如何授权对应用程序的访问?
最简单的想法是给用户分配权限:

  • Mo是管理员,可以做任何事情
  • Alice是开发人员,有只读权限

这个授权系统是有用的,但有一个限制:

  • 每次添加用户都要重新分配权限
  • 更糟糕的是,所有的权限都是重复的
  • 如果你要取消所有用户的写权限,你必须编辑所有的用户。

有什么办法?

与其直接给用户分配权限,你可以把它们分配给一个通用的配置文件:

  • 创建一个配置文件 "admin "并分配所有的权限
  • 然后可以创建有一个 "dev",拥有只读权限

最后,你可以将这些通用配置文件分配给用户:

  • Mo是 "admin"
  • Alice是 "dev"

如果有一个新的开发人员加入团队,你可以将他再次分配到 "dev "配置文件:
这些配置文件通常被称为角色
这就是你如何拥有基于角色的访问控制(RBAC)。

资源
现在我们已经讨论了如何授予权限,现在是时候看看资源了:
你要给什么东西授予访问它的权限?
在Kubernetes中,我们授予对API端点的访问权:

  • 例如:你可以列出Pod,但不能列出Secrets
  • 或者:你可以使用默认命名空间,但不能使用kube-system

那么用户呢?
在Kubernetes中,角色可以分配给外部用户(人类!)或机器人(集群内的应用程序)。
你也可以拥有两者混合的群组。

所以我们来回顾一下:

  • 有用户(人类、机器人、组)。
  • 创建角色,向API端点授予权限
  • 将角色与用户联系起来

最后一步叫做绑定,通常是通过另一个叫做RoleBinding的对象来完成的,它把身份和角色联系起来。

不过,有一件事要记住:
角色和角色绑定是在一个命名空间中创建的,它们授予对当前命名空间中的资源的访问权。

如果你想授予全局资源的访问权,比如节点或持久化卷,会发生什么?

全局资源访问
如果有一种方法可以将一个配置文件定义为全局性的,而不是局限于一个命名空间,那就更好了
那么,你刚刚发明了ClusterRole--一个适用于整个集群的全局角色

为了将一个身份链接到一个全局角色,我们使用ClusterRoleBinding

当你把一个 "标准 "的ClusterRole链接到一个RoleBinding时会发生什么?
这可能吗?
是的。
用户将拥有ClusterRole的所有权限,但范围是RoleBinding的当前命名空间。


最后是一些我认为有用的kubectl命令:

  • - 用 "kubectl --as=jenkins "进行用户身份认证
  • - 用 "kubectl auth can-i "验证API访问。

你也可以把它们结合起来。