context中的user信息是否可以增加一下扩展信息

Imy123

目前使用中发现context中user的信息只有name和group，如果想对user加一些扩展信息在context中就无法获取到，在实际使用中不是很方便。
比如租户A的用户张三登陆系统创建了一个边缘设备，后端通过张三的token解析出user的名称是张三，但是如果想知道张三属于哪个租户，就需要通过WorkspaceRoleBinding来查询到对应的租户。感觉流程有点繁琐。如果可以讲CR user 的annotation和label放到context中user的Extra字段中，后端直接就可以解析到用户的扩展信息，不需要再做额外的操作，比如在annotation中放入租户的信息 tenant: test01,后端在创建边缘设备时可以直接将租户信息添加到边缘设备的annotation中。在查询边缘设备时方便根据租户进行隔离

hongming

Imy123 在 KS/K8s 的设计中 user 不直接与资源进行关联，资源只归属于 cluster、workspace、namespace

我大概理解你的意思，你希望将边缘设备分配给不同的 workspace 使用是吗？可以看看 KS 中 workspace 与 namespace
还有 cluster 之间的关联方式。

边缘设备归属于集群

POST /(k)apis/devices.kubeedge.io/v1alpha1/devices

边缘设备归属于企业空间

POST /(k)apis/devices.kubeedge.io/v1alpha1/workspaces/{workspace}/devices

hongming

Imy123 资源层级都需要在 API path 中得到体现，查询的时候也是类似

Imy123

hongming 我是希望在创建边缘设备的时候给这些设备加一些标签和annotation来标识这些设备属于哪一个租户的，然后查询租户信息需要从context中获取user，从user中根据workspacerolebinding查询该user属于哪一个租户，我觉得可以把租户的信息放到user的annotation中，创建设备的时候直接从user中获取到租户信息，操作上简单一些。不知道这个方案可不可行

hongming

Imy123 不太对， workspace 是租户单元，user 和 worksapce 不是一一对应的，资源归属 workspace ，这种归属关系不是通过 context 去传递的， context 里只传递请求用户的身份信息，比如说设备归属哪个 workspace，这个属于API设计的范畴，应该从 API path 中获取，request info 这个 context 里会有相关信息

hongming

Imy123 看看API 的设计 https://kubernetes.io/docs/reference/using-api/api-concepts/

Imy123

hongming 就是说user是可以同时属于多个workspace的是吗

hongming

Imy123 是啊，任何资源都是跟 user 没有直接关系的

Imy123

hongming 我把workspace理解成租户了，如果一个用户可以同时属于多个workspace，这样就做不到租户之间的账户隔离了，我的方案就行不通了

Imy123

hongming ks目前支持多租户吗

hongming

Imy123 你可以先理解一下资源的层级关系，再看看 https://kubernetes.io/docs/reference/using-api/api-concepts/这个 API 模式，结合 K8s 的 RBAC 一起看，你就明白了

Imy123

hongming 这个我知道，感觉ks 的账户设计和我们公司的业务不是太吻合，ks账户体系的设计有相关的文档可以查看吗

hongming

Imy123 官方文档翻一翻，都有写的

Imy123

hongming 你们的账户设计满足不了多租户需求吧

hongming

Imy123 这个看你怎么理解了，你所定义的多租户有哪些需求呢？软多租户（企业PaaS）场景下，KS 目前已经实现了基于 namespace/workspace/cluster 不同层面的数据的逻辑隔离。硬多租户（SaaS）场景下，目前只支持网络隔离，但稍加改造也可以实现运行时、物理机网络的硬隔离