Kasten k10 云原生应用安全系列 04 – 深度解读 Kasten K10 RBAC 基于角色的访问控制机制

本文主要内容

RBAC 简介
RBAC 在 Kubernetes 上的应用
使用 RBAC 为多租户环境配置 Kasten K10
总结
参考文献

前言

由于备份是应对勒索病毒攻击等威胁的最后一道防线，因此对备份环境的访问机制的保护尤为重要。作为领先的 Kubernetes 备份和恢复解决方案，Kasten K10 by Veeam 提供了保护 K10 环境所需的细粒度身份和访问管理控制，并可轻松为用户提供其角色所需的访问权限。在这篇文章中，我们将详细讲解 Kasten K10 中基于角色的访问控制 (RBAC) 功能。

1. RBAC 简介

基于角色的访问控制（Role-based access control，RBAC），是在现代化信息安全领域中得到广泛使用的访问控制机制，其不同于强制访问控制以及自由选定访问控制直接赋权的方式，而是将权限赋予角色。1996年，Ravi Sandhu 等人在前人的理论基础上，提出以角色为基础的访问控制模型，故该模型又被称为 RBAC96。在此之后，美国国家标准局重新定义了以角色为基础的访问控制模型，并将之纳为一种标准，称之为 NIST RBAC。

RBAC - 基于角色的访问控制
 https://en.wikipedia.org/wiki/Role-based_access_control

shi'jian

2. RBAC 在 Kubernetes 上的应用

在 Kubernetes 中，访问控制分为三个部分：请求认证、授权和准入控制，关于认证这一部分，可以参考我上一期的文章，我们主要讨论赋权或鉴权。RBAC 赋权或鉴权的机制可以理解为：判断 Who 即谁，是否能以 How 怎么样的方式访问与操作 What 什么资源。如下图，Kubernetes 中的资源都是 API Resources。Subject 中的 Role 角色，或是被赋予角色的用户，可以按照规则对，各种资源进行类似 CURD 增删改查的操作。

20220924064846

Kubernetes API 访问控制
 https://kubernetes.io/zh-cn/docs/concepts/security/controlling-access/
基于角色的访问控制最佳实践
 https://kubernetes.io/zh-cn/docs/concepts/security/rbac-good-practices/

3. 使用 RBAC 为多租户环境配置 Kasten K10

在与客户的对话中出现的一个常见要求是，他们希望 Kasten 的数据管理平台 K10 提供多租户的访问与控制。在 Kasten by Veeam，我们通过与 Kubernetes 基于角色的访问控制 (RBAC) 进行本地集成来实现这一目标。在本文中，我们将从 ClusterRoles 和 Roles 说明开始，再来说明通过角色绑定或集群角色绑定在 kasten k10 上的应用，以便根据操作需要对我们的 k10 实现进行精细访问控制。

由于 Kasten 利用 Kubernetes 的原生 RBAC，用户在定义各种类型的角色和为每个角色分配不同级别的权限时具有很大的灵活性。Kasten 可以通过图形界面，方便的对角色访问控制进行管理。如下图，的蓝色部分是 Kasten K10 中有默认存在的 ClusterRoles 角色和 Roles，而红色部分是客户自定义的ClusterRoles 角色和 Roles，我们将对这两部分进行分别的介绍。

3.1. Kasten K10 中的 ClusterRoles 和 Roles 的配置与赋权

我们将 Kasten K10 中的 ClusterRoles 和 Roles 详细情况列表如下，在本文中，我们通过对重点角色的讲解与对比，说明如何进行细粒度的权限控制。详细说明还请查阅 K10 RBAC 的相关文档。

ROLE NAME	Role TYPE	ACCESS LEVEL
k10-admin	ClusterRole	可访问和操作所有资源，无限制
k10-basic	ClusterRole	基于有限资源访问
k10-config-view	ClusterRole	基于配置查看功能
k10-mc-admin	ClusterRole	多集群管理角色
k10-ns-admin	Role	kasten-io 命名空间管理员

Kasten K10 RBAC
https://docs.kasten.io/latest/access/rbac.html

3.1.1. k10-admin ClusterRole

让我们举个例子，k10-admin 就是 Kasten K10 的管理员角色，k10-k10 这个用户或是 Service Account，将被授权为 k10-admin 这个角色，如何实现呢？当然就是 Rolebinding 或是ClusterRolebinding 。注意， k10-k10 是 Kasten 系统默认生成的，我们先以 K10 自身的的配置做为鲜活的例子，让大家可以快速理解。值得称道的是，在 Kasten K10 这个 RBAC 的管理范围里，无论命令行还是图形管理都非常方便。

首先，我们来看看 k10-admin 具备哪里能力，在 PolicyRule 中我们看到 Verbs 这里的 * 是证明 k10-admin 可以操作任何的资源。这个资源都是 Kasten 的 CRDs，CRDs 前面的* 则是可以操作任何的资源。

$ kubectl get clusterrole |grep k10
k10-admin                                                              2022-09-20T15:01:09Z
k10-basic                                                              2022-09-20T15:01:09Z
k10-config-view                                                        2022-09-20T15:01:09Z
k10-mc-admin                                                           2022-09-20T15:01:09Z

$ kubectl describe clusterrole k10-admin
Name:         k10-admin
Labels:       app=k10
              app.kubernetes.io/instance=k10
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=k10
              helm.sh/chart=k10-5.0.8
              heritage=Helm
              k10.kasten.io/default-rbac-object=true
              release=k10
Annotations:  meta.helm.sh/release-name: k10
              meta.helm.sh/release-namespace: kasten-io
PolicyRule:
  Resources                  Non-Resource URLs  Resource Names  Verbs
  ---------                  -----------------  --------------  -----
  *.actions.kio.kasten.io    []                 []              [*]
  *.apps.kio.kasten.io       []                 []              [*]
  *.config.kio.kasten.io     []                 []              [*]
  *.cr.kanister.io           []                 []              [*]
  *.reporting.kio.kasten.io  []                 []              [*]
  *.vault.kio.kasten.io      []                 []              [*]
  namespaces                 []                 []              [create get list]

$ kubectl get crd |grep kasten.io
bootstraps.dist.kio.kasten.io                         2022-09-20T15:07:49Z
clusters.dist.kio.kasten.io                           2022-09-20T15:07:50Z
distributions.dist.kio.kasten.io                      2022-09-20T15:07:50Z
k10clusterrolebindings.auth.kio.kasten.io             2022-09-20T15:07:50Z
k10clusterroles.auth.kio.kasten.io                    2022-09-20T15:07:50Z
policies.config.kio.kasten.io                         2022-09-20T15:07:50Z
profiles.config.kio.kasten.io                         2022-09-20T15:07:50Z
reports.reporting.kio.kasten.io                       2022-09-20T15:07:50Z

那么这些 CRDs 又包含哪里对象的定义呢，借用图形界面一张图即可清晰的说明。详细的解释，可参考 Kasten K10 的手册。

Kasten K10 CRDs and Kubernetes API Aggregation
https://docs.kasten.io/latest/api/cli.html

我们再来看一下把角色和权限联系起来的 ClusterRoleBinding，可以发现，k10-k10 这个 ServiceAccount 被赋予了 k10:admins Group 的权限。

$ kubectl get ClusterRoleBinding |grep k10
k10-mars-basic-crb                                     ClusterRole/k10-basic                                                              42h
kasten-io-k10-k10-admin                                ClusterRole/k10-admin                                                              3d11h
kasten-io-k10-k10-cluster-admin                        ClusterRole/cluster-admin                                                          3d11h

$ kubectl get ClusterRoleBinding kasten-io-k10-k10-admin
NAME                      ROLE                    AGE
kasten-io-k10-k10-admin   ClusterRole/k10-admin   3d11h

$ kubectl describe ClusterRoleBinding kasten-io-k10-k10-admin
Name:         kasten-io-k10-k10-admin
Labels:       app=k10
              app.kubernetes.io/instance=k10
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=k10
              helm.sh/chart=k10-5.0.8
              heritage=Helm
              release=k10
Annotations:  meta.helm.sh/release-name: k10
              meta.helm.sh/release-namespace: kasten-io
Role:
  Kind:  ClusterRole
  Name:  k10-admin
Subjects:
  Kind   Name        Namespace
  ----   ----        ---------
  Group  k10:admins

k10-k10 这个用户登录时的效果，这是一个没有被限制权限的超级用户。

这个超级用户可以让我们定义管理员和基本用户的权限，在此我们列出只能为管理员用户完成的操作示例。以下是只能由管理员用户完成的任务示例：	#	管理员用户操作
1	创建数据保护策略，保护 K8S Cluster 中的任何应用程序
2	创建备份存储库及其配置文件
3	列出任何命名空间中所有类型的用户创建的操作

3.1.2. k10-basic ClusterRole

对于 K10 的管理员，k10-basic ClusterRole 对于希望向特定命名空间中的用户授予某些操作的访问权限特别实用, 比如负责某个命名空间中数据库备份的开发人员。

#建立一个 ServiceAccount 用于对 Namespace mysql 进行备份
$ kubectl create serviceaccount k10-mysql-backup -n mysql

#建立这个 ServiceAccount 的 Secret 或是 Token 用于登录
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: k10-mysql-backup-secret
  annotations:
    kubernetes.io/service-account.name: k10-mysql-backup
type: kubernetes.io/service-account-token
EOF

#建立这个 rolebinding ，将这个角色赋与 k10-basic 权限
$ kubectl create rolebinding k10-mysql-backup-rb --clusterrole=k10-basic --serviceaccount=mysql:k10-mysql-backup --namespace=mysql
rolebinding.rbac.authorization.k8s.io/k10-mysql-backup-rb created

关于 K10-Basic 权限的视图

我们可以看到这个用户是被限制了权限的，他只能看到自己应用所属的命名空间。
20220925154818
他只能看到自己的应用所属的备份策略
20220925155558
他不能改变 RBAC 策略
20220925155710

3.1.3. k10-ns-admin Role

k10-ns-admin 角色，用于对 K10 命名空间 kasten-io 中的资源进行访问。

$ kubectl describe role k10-ns-admin -n kasten-io
Name:         k10-ns-admin
Labels:       app=k10
              app.kubernetes.io/instance=k10
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=k10
              helm.sh/chart=k10-5.0.8
              heritage=Helm
              k10.kasten.io/default-rbac-object=true
              release=k10
Annotations:  meta.helm.sh/release-name: k10
              meta.helm.sh/release-namespace: kasten-io
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
  secrets           []                 []              [create delete get list update]
  deployments       []                 []              [get list]
  pods              []                 []              [get list]
  deployments.apps  []                 []              [get list]
  pods.apps         []                 []              [get list]
  jobs.batch        []                 []              [get]

3.2. 用户自定义 Role 角色的配置与赋权

从 Kasten 5.0 开始，用户可以在界面上方便的定义角色，如下图，我们定义了一个 mysql-backup 的角色，并且您可以一眼就看到，他对于 K10 的资源是否有读，写，删除的能力。

这些能力可以在创建用户的时候方便地通过 “打勾” 方式来进行选择，选择 Role Level 时 Entire Cluster 或是 Specific Applications 将会决定您创建一个 ClusterRole 还是一个基于 Namespace 的 Role，当选择 Specific Applications 时，您可以方便的添加希望被管理的 Namespace

如果希望将用户自定义的 Role 角色分配给用户，只需要建立一个新的 Assignment 。之后的效果与操作就与 K10-basic 角色分配时类似了，在这里我们不在赘述。

20220925161829

4. 总结

Kasten K10 作为云原生数据管理平台，专为 Kubernetes 而构建，符合 Kubernetes 的安全标准，旨在为企业运营团队提供一个易于使用、可扩展且安全的数据管理平台，助力企业实现 Kubernetes 应用程序的备份恢复、灾难恢复和应用移动性。本文我们介绍了如何通过 Kasten 的 RBAC 管理功能来满足客户在多个 Kubernetes 集群中，不同类型用户同时工作的日常数据管理需求。希望您可以很好的利用 Kasten K10 中原生的 RBAC 功能的并告知我们您的体验。想了解更多 K10 中对于角色与权限的定义，可以查看 Kasten.io 上的文档。

5. 参考文献

RBAC - 基于角色的访问控制
 https://en.wikipedia.org/wiki/Role-based_access_control
Kubernetes API 访问控制
 https://kubernetes.io/zh-cn/docs/concepts/security/controlling-access/
基于角色的访问控制最佳实践
 https://kubernetes.io/zh-cn/docs/concepts/security/rbac-good-practices/
Kasten K10 RBAC
https://docs.kasten.io/latest/access/rbac.html
Kasten K10 CRDs and Kubernetes API Aggregation
https://docs.kasten.io/latest/api/cli.html

一	二	三	四	五	六	日
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31