We have several use cases where dynamic plugins need to proxy to another service on the cluster. One example is the Helm plugin. We would like to move the backend code for Helm to a separate service on the cluster, and the Helm plugin could proxy to that service for its requests. This is required to make Helm a dynamic plugin. Similarly if we want to have ACM contribute any views through dynamic plugins, we will need a way for ACM to proxy to its services (e.g., for Search).
It's possible for plugins to make requests to services exposed through routes today, but that has several problems:
- It requires that the service be exposed outside the cluster, which is not always desired.
- It requires the service support CORS headers for the console.
- There is no way to specify a CA file for the route if it's not trusted by the browser.
- Plugins will not have access to the user's access token on the client, which means that there is no simple way to handle auth.
Plugins need a way to declare in-cluster services that they need to connect to. The console backend will need to set up proxies to those services on console load. This also requires that the console operator be updated to pass the configuration to the console backend.
This work will apply only to single clusters.
- What happens when a multitenant isolated network policy is configured on the cluster?
- How do we (and can we?) support this for multi-cluster where console is running on a different hub cluster?
- Do we need to auth for all requests?
- Plugins can declare a service to proxy to in the ConsolePlugin resource
- Plugins can specify a CA cert for the service
- Console falls back to the service signing CA if none is specified
- Plugins have a way of specifying whether the user's authentication token is included in requests through the service proxy
- Dynamic plugin enhancement is updated with the implementation details
- Support for server-side events (SSE) for ACM
- Add support, or a flag, if auth is needed for each request.