Skip to content

feat(virtual-browser-jupyter): add managed Chromium policy and pin base image - #464

Draft
june-hua wants to merge 2 commits into
virtual-browserfrom
june/rbi-chromium-policy
Draft

feat(virtual-browser-jupyter): add managed Chromium policy and pin base image#464
june-hua wants to merge 2 commits into
virtual-browserfrom
june/rbi-chromium-policy

Conversation

@june-hua

Copy link
Copy Markdown
Contributor

Stacks on #463. Adds the Chromium configuration that template was missing, pins the base image into
the repo's version-tracking system, and fixes a couple of template-metadata issues.

Changes

  • policies/managed-policy.json (new) — a managed Chromium enterprise policy, copied into
    /etc/chromium/policies/managed/ in browser.Dockerfile. Chromium reads every *.json in that
    directory at startup and applies it as immutable, so these settings can't be changed from within
    the session. Configures the session as a single-purpose app view: navigation pinned to the app URL,
    downloads/printing/file-dialogs off, devtools and extensions off, clipboard and popups off.

    It's baked into the image deliberately rather than mounted — the compose context is mounted as the
    user's writable workspace, so a mounted policy file would be editable from inside the session.

  • Base image pinnedlscr.io/linuxserver/chromium@sha256:4c7b9086… instead of :latest, with a
    matching entry in feature-versions/state.json so update.sh tracks it. Note the existing
    src/.*/Dockerfile filters do not match browser.Dockerfile, so a dedicated entry with its own
    filter is required.

  • docker-compose.yaml — moved shm_size/mem_limit onto the app service. Those template
    options are computed by 050-parse-devcontainer.sh for the container named application-server,
    which is the browser; Chromium is also the container that actually needs the shared memory. Added
    --app=/--force-app-mode/--start-fullscreen to CHROME_CLI, keeping the existing proxy
    restriction.

  • Template metadatadevcontainer-template.json had id: "custom-workbench-jupyter-template"
    copied from another template, which collides with two existing directories and would conflict on
    publish. Gave it its own id/name/description.

  • README.md — operational documentation for the template: what it is, which browser features
    are unavailable, how to point it at a different app, how to build locally.

Verified

Built the image locally: the pinned digest resolves and pulls, and the policy file is present at
/etc/chromium/policies/managed/workbench-rbi.json in the built image.

Needs review / testing

  • DefaultClipboardSetting: 2 may also block pasting into the session. Worth testing before
    this leaves draft — researchers paste code frequently and that would be daily friction.
  • URLAllowlist must stay in sync with the CHROME_CLI app URL. Changing one without the other
    breaks navigation. Possible follow-up: derive both from a single template option.
  • Sibling templates' READMEs carry an "auto-generated from devcontainer-template.json" footer, but the
    generator workflow is workflow_dispatch-only and last ran in March 2024. I hand-wrote this README
    and dropped the footer rather than leave an inaccurate claim. If you'd prefer to keep it
    regeneration-safe, the prose should move to NOTES.md instead — happy to switch.

…se image

- Add policies/managed-policy.json and bake it into the browser image at
  /etc/chromium/policies/managed/workbench-rbi.json.
- Pin lscr.io/linuxserver/chromium by digest and register it in
  feature-versions/state.json so update.sh keeps it current.
- Run Chromium in app mode against the JupyterLab URL via CHROME_CLI.
- Make the browser the served app: shmSize/memoryLimit now apply to the
  application-server (browser) container, and jupyterlab publishes no ports.
- Give the template its own id/name/description and a user-facing README.
Chromium's remote debugging interface is not enabled by default in this
image, but the policy is the durable place to keep it off: it overrides
command-line flags, so the debug port stays closed even if
--remote-debugging-port is added later. Verified against the built image
that Chromium refuses to open the port when explicitly forced.

Note --remote-debugging-address makes the port bind 0.0.0.0 rather than
loopback, so this matters wherever the container shares a network with
other containers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant