[Feature Claim] dashboard backend k8s api should be cloud native

[huiwq1990]

• Title: feature title
• Description: your thoughts about this feature

If openyurt is a kubernetes with the featrue support edge node, the dashboard should use kubernetes opeanapi to access openyurt backend server.
Currently, the backend server wrap workload apis like deployment api. I think it's better use a kubernetes apiserver proxy to implements these apis.

[luc99hen]

Actually, this has been discussed when the experience center project was launched.

For dashboard alone, it's more elegant to use kubernetes openapi. But experience center backend server needs more than a proxy server because the user register function requires the admin privilege certificate which should not be accessed by the frontend (or the experience center users).

[luc99hen]

I think this could be considered when dashboard has been decoupled from the experience center project.

[huiwq1990]

If openyurt does not want to expose some crds or apis to end user. The k8s proxy could proxy add some permission restrictions. If openyurt has two user roles which are admin and normal. K8s proxy clould map openyurt user role to k8s rbac role, the feature is implement by k8s impersonation.

demo command:

kubectl auth can-i delete pod  --as usea

[luc99hen]

Thank you for your suggestion. This is inspiring. Let me sort out the discussion now.

1. it's more elegant and maintainable to use k8s openapi rather than wrapping them in the backend server
2. some function specific for experience center needs more than a proxy server
3. the permission related issues could be bypassed with k8s impersonation feature

And to my understanding, there are still two problems to be solved if we migrate to the openapi.

1. It's still the permission issue with the admin user role. Admin privilege is needed when user related operations are involved such as register and login. And this is why the backend server needs a kubeconfig with admin privileges of cluster to set up in advance. This this privilege should not be exposed to the frontend. I wonder if there is a workaround here.
2. Currently, there are two types of backend apis in terms of the complexity. First is the workload apis mentioned above which is just simply wrapped and can be easily transformed into openapi form. Another set of apis are more complex and involves some business logic, such as the lab related apis. These are difficult and unnecessary to conform to openapi.

What do you think? @huiwq1990

[huiwq1990]

There is nothing special for Experence Center, all we need to do is permission management. There are two types of openapi which are k8s openapi and openyurt dashboard openapi. So each of openyurt permission roles should cover the two type openapis. For example, openyurt admin users have permissions to manage users(dashboard openapi) and delete nodepool(k8s openapi), normal users have permissions to edit self profile(dashboard openapi) and view nodepool(k8s openapi)

[huiwq1990]

@luc99hen k8s apiserver proxy demo code can be find at https://github.com/huiwq1990/yurt-dashboard/tree/feat-k8s-proxy/openyurt-apiserver-proxy