kubernetes CRD 权限管理

Posted 2023-05-08

参考技术A 对于一个多个用户的集群而言，通常单个用户只有自己 namespace 的相关权限，而 kubernetes CRD 需要配置额外的权限才能使用。
我们尝试创建了一个 scalings 资源，对于拥有 Admin 权限的用户没有问题，但是对于普通用户，创建时则会提示：

当前 kubernetes 通常采用 RBAC(Role-Based Access Control) 的授权管理方式，可以很好的实现资源隔离效果。

这种方法引入了几个概念: Role, ClusterRole, RoleBinding, ClusterRoleBinding

Role 表示角色，每一个角色都可以定义一些规则表征这个角色对哪些资源有哪些操作的权限。Role 和 ClusterRole 的区别就在于 Role 是区分 Namespace 的，而 ClusterRole 则是整个集群的权限。

比如如下的配置表示 Role pod-reader 拥有对 default Namespace 的 pods 的只读权限。

接着我们需要将这个 Role 和具体的用户绑定起来使其生效。

通过这两个配置，jane 这个用户就具备了 default Namespace 的 pods 资源的只读权限。

ClusterRole 和 ClusterRoleBinding 的使用姿势没有太大区别，只是作用域是整个集群，不需要指定 Namespace。

CustomResourceDefinition 存在于所有 namespace 下，所以需要创建 ClusterRole 和 ClusterRoleBinding 来让普通用户拥有操作 CRD 的 admin 权限。

参考配置如下:

kubectl apply 该配置，则 test 用户具备了对 customresourcedefinitions.apiextensions.k8s.io 的所有操作权限，可以正常创建，删除，更新 CRD 资源。

但是对于我们通过 CRD 创建出来的自定义资源，例如 scalings.control.example.com，还没有任何权限，不能创建和查看对象。

对于 scalings.control.example.com 这样的我们自己创建出来的资源，也需要对普通用户授予权限，但是不需要是集群范围内的，只需要授予用户关联的 namespace 下的权限即可。所以可以通过创建新的 Role 和 RoleBinding 来实现这一能力。

参考配置如下:

kubectl apply 该配置，则 test 用户可以正常创建和查看 scalings 资源对象。

Kubernetes自定义资源（CRD）

参考技术A Kubernetes系统拥有强大的高扩展功能，其中自定义资源（Custom Resource）就是一种常见的扩展方式，即可将自己定义的资源添加到Kubernetes系统中。Kubernetes系统附带了许多内置资源，但是仍有些需求需要使用自定义资源来扩展Kubernetes的功能。

在Kubernetes系统早期，是通过 ThirdPartyResource（TPR） 来实现扩展自定义资源的，但自Kubernetes 1.7版本后，ThirdPartyResource功能已被弃用，并且其已根据Beta功能的弃用政策在Kubernetes 1.8中被删除，取而代之的是 CustomResourceDefinitions（自定义资源定义，简称CRD） 。

开发者通过CRD可以实现自定义资源，它允许用户将自己定义的资源添加到Kubernetes系统中，并像使用Kubernetes内置资源一样使用这些资源，例如，在YAML/JSON文件中带有Spec的资源定义都是对Kubernetes中的资源对象的定义，所有的自定义资源都可以与Kubernetes系统中的内置资源一样使用kubectl或client-go进行操作。

当你创建新的 CustomResourceDefinition（CRD）时，Kubernetes API 服务器会为你所指定的每一个版本生成一个 RESTful 的资源路径。CRD 可以是命名空间作用域的，也可以是集群作用域的，取决于 CRD 的 scope 字段设置。和其他现有的内置对象一样，删除 一个命名空间时，该名字空间下的所有 CRD 对象也会被删除。CustomResourceDefinition 本身是不受命名空间限制的，对所有命名空间可用。

例如，如果你将下面的 CustomResourceDefinition 保存到 resourcedefinition.yaml 文件：

之后创建它：

这样一个新的受名字空间约束的 RESTful API 端点会被创建在：

此端点 URL 自此可以用来创建和管理定制对象。对象的 kind 将是来自你上面创建时 所用的 spec 中指定的 CronTab。

创建端点的操作可能需要几秒钟。你可以监测你的 CustomResourceDefinition 的 Established 状况变为 true，或者监测 API 服务器的发现信息等待你的资源出现在那里。

在创建了 CustomResourceDefinition 对象之后，你可以创建定制对象（Custom Objects）。定制对象可以包含定制字段。这些字段可以包含任意的 JSON 数据。 在下面的例子中，在类别为 CrontTab 的定制对象中，设置了 cronSpec 和 image 定制字段。类别 CronTab 来自你在上面所创建的 CRD 的规约。

如果你将下面的 YAML 保存到 my-crontab.yaml ：

并执行创建命令：

你就可以使用 kubectl 来管理你的 CronTab 对象了。例如：

应该会输出如下列表：

使用 kubectl 时，资源名称是大小写不敏感的，而且你既可以使用 CRD 中所定义的单数 形式或复数形式，也可以使用其短名称：

你可以看到输出中包含了你创建定制对象时在 YAML 文件中指定的定制字段 cronSpec 和 image：

当你删除某 CustomResourceDefinition 时，服务器会卸载其 RESTful API 端点，并删除服务器上存储的所有定制对象。

如果你在以后创建相同的 CustomResourceDefinition 时，该 CRD 会一个空的结构。

使用 CustomResourceDefinition 扩展 Kubernetes API
Kubernetes CRD 系列：CRD 介绍