Plugins for everyone

plugins:
  queues.yaml: |
    apiVersion: lumovi.dev/v1beta1
    kind: Plugin
    metadata: { name: queues }
    spec:
      version: 1.0.0
      needs:
        lumovi: 1.22.0
      groups: [messaging.example.com]
      views:
        - kinds: [{ group: messaging.example.com, kind: Queue }]
          columns: [{ name: Depth, path: .status.depth, type: number }]
  platform.yaml: |
    apiVersion: lumovi.dev/v1beta1
    kind: Plugin
    metadata: { name: platform }
    spec:
      version: 1.0.0
      needs:
        lumovi: 1.22.0
      groups: [platform.example.com]
      label: Platform
      kinds: [{ group: platform.example.com, kind: Database }]

​

How it works

• The chart puts the files in a ConfigMap, and mounts it at /etc/lumovi/plugins, where Lumovi reads them (LUMOVI_PLUGINS_DIR). Kubernetes mounts each file as a link, which Lumovi follows.
• A kind is one plugin’s. These plugins show kinds no other plugin has; one with the name of one of Lumovi’s, like flux or cert-manager, is used in its place, all of it, and All plugins says so to everyone on its row.
• They’re held as Lumovi’s own are: a tool’s kinds in the groups the plugin names, none of Kubernetes’ own but the few it may show, and nothing created but the plugin’s own kinds.
• A change to plugins rolls out a new pod, which reads them. People stay signed in, as across any restart, and open pages reconnect.
• Without the chart, put the files in the folder LUMOVI_PLUGINS_DIR names. Lumovi reads it again whenever a page loads, so people see a change when they reload.
• These plugins are the server’s, for everyone. What goes here is described, never code: only the plugins Lumovi comes with have code. People can’t add their own from a browser.
• In a fleet, they’re for every cluster: a view of a kind is used in each cluster that has that kind, and a plugin’s place in the sidebar shows in each cluster that serves one of its kinds.

​

Check them

​

Plugins’ code

• LUMOVI_URL is set, so the box has an address of its own, at plugin-box/box.html below it, beside the check’s own frame at plugin-box/check.html. See The page.
• The browser’s requests are held to Lumovi’s own page, as auth.secFetchSite does by default. Behind a sign-in proxy, only where auth.proxy.secFetchSite says the proxy passes the header through.
• Lumovi has checked that browser. The first time someone opens such a page, Lumovi checks that their browser keeps a plugin’s code in its box: that it can’t reach the network, Lumovi’s page, cookies or storage, or another plugin’s box. A browser that fails isn’t handed any plugin’s code, and the page says so, like “Lumovi checked this browser and it didn’t pass, so it doesn’t run plugins’ code in this browser. Another browser may pass the check.” Each check is in the audit log as plugin.box-check. The check asks Lumovi at box-check/ below LUMOVI_URL, from sealed frames in the browser. So whatever stands in front of Lumovi (an ingress that lists its paths, a firewall for web requests, a sign-in proxy) must pass everything there on, as it passes the rest, including these, which come from no site of their own: requests that say Origin: null; requests that say no origin and don’t come from Lumovi’s own page; and WebSocket upgrades that say Origin: null. None of them carries the sign-in proxy’s cookie. Where they don’t arrive, no plugin’s code runs in that browser. The page says “Lumovi couldn’t check this browser: its own test request didn’t reach this server, so it can’t tell what a plugin’s box lets out here.”, and Lumovi’s log says which didn’t arrive.
• This server runs that plugin’s code, as pluginCode says.

pluginCode: true                  # every plugin's, the default
# pluginCode: false               # none
# pluginCode: [karpenter, argo-cd]  # only these