Page MenuHomePhabricator

[superset-k8s] Find a solution for the requestctl-generator html page
Closed, ResolvedPublic

Description

The requestctl-generator html page is currently co-hosted with superset to allow the JS to call the superset API to get the data it needs.

The apache rule is currently defined here.

With the move to docker and OIDC we probably need to find a solution for this to keep it working.

Event Timeline

Gehel triaged this task as High priority.Feb 6 2024, 2:56 PM
BTullis renamed this task from Find a solution for the requestctl-generator html page to [superset-k8s] Find a solution for the requestctl-generator html page.Feb 6 2024, 4:20 PM

I investigated how we could solve this, and we have 2 different ways I think we could re-implement the current behavior in k8s.

First, we could inject a custom Flask blueprint into superset from within the superset_config.py config file, that would look like this:

# superset_config.py

...

from flask import Blueprint

rqctl = Blueprint('requestctl-generator', __name__, url_prefix='/requestctl-generator')

@rqctl.get('/')
def serve_requestctl_generator_page():
    with open('path/to/requestctl-generator.html') as f:
        return f.read()

BLUEPRINTS = [rqctl,]

Superset would automatically load the custom behavior at startup time. However, I haven't yet found how to apply the same security requirements to the blueprint as the rest of the Superset API (OIDC login required), meaning that the static page would be openly accessible.

@BTullis and I don't think it's huge deal, because the javascript API calls _would_ require a OIDC session token to work in the first place, so visiting https://superset.wikimedia.org/requestctl-generator would simply allow the visitor to see the page source code, but not perform any API call. On top of that, the html source code is already out in the open, as it's currently part of our puppet repository.

If however that is a no-go from a security standpoint, we would add another envoy backend rule behind /requestctl-generator that would redirect to an nginx / apache container serving the HTML static page, configured with CAS login integration, as we currently have on an-tool1005/an-tool10010.

I'm moving this into the current milestone, because we're effectively working on it together as part of T357890: Serve Superset static assets from an optimised container.

Our latest thinking is to use an nginx reverse proxy to serve the static assets for Superset.
This reverse proxy will also be able to serve the request-generator HTML page.

Now that the reverse proxy container is in place, with the statics on the filesystem, we should add the requestctl-generator page to it as well

Change 1006923 had a related patch set uploaded (by Brouberol; author: Brouberol):

[operations/deployment-charts@master] superset: serve the requestctl-geneerator static page

https://gerrit.wikimedia.org/r/1006923

Change 1006923 merged by Brouberol:

[operations/deployment-charts@master] superset: serve the requestctl-geneerator static page

https://gerrit.wikimedia.org/r/1006923