Description
Build a prototype that displays UI hosted in the service deployed in the same Kubernetes cluster the user is connected to. Several options should be explored and compared:
Custom datasource
A simple solution that enabled modules to expose own backend only. The UI is still based on busola extensibility. The idea is that the extension can register data sources with the relative URL like: /api/v1/namespaces/default/services/nginx-service/proxy/data.json that will be proxied by the busola backend.
External application
Busola can host declared services using user credentials stored in the session cookie. User can open the module UI directly in the browser, because authorization headers are not required. Example: https://dashboard.stage.kyma.cloud.sap/cluster/garden-kyma-xxxx-external/namespaces/default/services/nginx-service/proxy/index.html
Load and execute script
Busola can load the script through the declared endpoint using a user token. Example: fetch script from
/backend/api/v1/namespaces/default/services/nginx-service/proxy/index.js and execute it passing the content div as a context.
For each option prepare a list of strengths and weaknesses including the following criteria:
security (e.g. loaded script can access session storage and access data from another cluster)
flexibility (what developers can do)
user experience (e.g. how we can ensure users perceive module UI as an integral part of the application)
Reasons
Some modules require custom UI that doesn't follow the convention of fetching and rendering Kubernetes resources. One example is fetching data from external URLs, another is using case-specific UI/UX that requires custom JS code.
How to start
Here is a quick prototype that can be used in the PoC that deploys a simple service with an index.html, and javascript file (index.js) that loads some data from the same service (data.json). The service is exposed using nginx.
Apply the script:
It looks we can integrate custom module UI with busola, with possibility to access custom API hosted inside kubernetes cluster using busola backend and session stored in cookies. Next steps will be:
document the concept and perform threat modeling for authorization flow
try different way of embedding module UI - custom web components instead of iframe
implement cookie based authentication/authorization in busola backend
Description Build a prototype that displays UI hosted in the service deployed in the same Kubernetes cluster the user is connected to. Several options should be explored and compared:
Custom datasource A simple solution that enabled modules to expose own backend only. The UI is still based on
busola
extensibility. The idea is that the extension can register data sources with the relative URL like:/api/v1/namespaces/default/services/nginx-service/proxy/data.json
that will be proxied by the busola backend.External application Busola can host declared services using user credentials stored in the session cookie. User can open the module UI directly in the browser, because authorization headers are not required. Example:
https://dashboard.stage.kyma.cloud.sap/cluster/garden-kyma-xxxx-external/namespaces/default/services/nginx-service/proxy/index.html
Load and execute script Busola can load the script through the declared endpoint using a user token. Example: fetch script from
/backend/api/v1/namespaces/default/services/nginx-service/proxy/index.js
and execute it passing the content div as a context.For each option prepare a list of strengths and weaknesses including the following criteria:
Reasons Some modules require custom UI that doesn't follow the convention of fetching and rendering Kubernetes resources. One example is fetching data from external URLs, another is using case-specific UI/UX that requires custom JS code.
How to start Here is a quick prototype that can be used in the PoC that deploys a simple service with an index.html, and javascript file (index.js) that loads some data from the same service (data.json). The service is exposed using nginx. Apply the script:
Start kubernetes proxy:
Open the web application: http://127.0.0.1:8001/api/v1/namespaces/default/services/nginx-service/proxy/