Review plugin configurations

For: tenant admins and governance reviewers.

Plugin configurations

A change of an installed plugin's configuration, from its Configure tab or oz0 plugin config apply, is one change request of kind plugin_config: every part it changes (settings, model mappings, function switches, budgets, the tenant's egress list, schedules), each with its value before and after, and every loosening listed first.

$ oz0 change show cr-509f13f6-8a1f
Change request cr-509f13f6-8a1f: plugin_config of notes, pending
  requested by operator:admin 0s ago
  Plugin notes's configuration:
  ! egress api.notes.example.com: not on the tenant's list -> allowed
      loosens: wider egress: host (a host or port the list did not allow)
    settings NOTES_TIMEOUT: not set -> 30s
    models agent noter asking for default: no rule (default as the tenant resolves it) -> e2e-small
    budgets noter: the definition's $0.10 a job tree, on_budget as the definition says -> $0.25 a job tree, on_budget wait
    schedules notes-nightly: fires -> paused
  reason: the notes API, a smaller model
You may not approve it: this configuration loosens a control (...), so another admin than operator:admin, who proposed it, approves it

Check whether another admin must approve

Loosenings are what the governance registry counts as one: an egress entry that widens what sandboxes may reach, an approval removed (Ask to Allow), a function turned on (Refuse to Ask or Allow), and a governance setting loosened (such as a classified marking allowed). A request with one is always approved by another admin than the one who asked, whatever the tenant's review says, and with four eyes off.

A plugin's configuration that loosens always waits for another admin; a function's switch that loosens waits for another admin only where four eyes are on: the install screen, plugin install --policy, plugin install --config's tools: and oz0 plugin policy --set change the tool policy directly, as a governance change (two paths).

A configuration request without a loosening follows the review: under confirm the requester may approve it after seeing it, under second_admin (or four eyes on) another admin does.

Check the approver's permissions

Approving takes, for each part, the permission its own command takes (settings.write; models.manage; governance.write for the switches, the egress list and governance settings; budget.manage; routines.run, which pauses and resumes routines). An approver without one is refused before anything is decided, so the request waits for someone who may.

Apply every part together

Applying writes every part at once. If one of them changed after the request was filed, or a write fails, nothing changes and the request ends failed, saying which part: file it again. Each part's audit entry (setting.set, model.map.set, tenant.tool_policy, agent.budget.set, tenant.egress, routine.pause, ...) is the approver's and names the request; the request's own are plugin.config.change_requested, _approved, _rejected and _applied.

Approvals of one tenant's configuration requests apply one at a time. A part that someone else changed while a request waited fails it, however close together the two approvals come.

When the change reaches work

Settings reach the plugin's processes at once; a model mapping applies to jobs that start after it; a budget to job trees that start after it.

Roll back an applied request

Every applied request can be rolled back (oz0 plugin config rollback <id>, or Roll back on the Changes tab and the Configure tab). It files a new request with the inverse diff, compared with the plugin as it is now, approved as any other: rolling back a refusal turns a function on again, so another admin approves it.

Replace a pending request

A new request for the same plugin supersedes the one that waited when the same person filed both, or when its requester may change every part the waiting one changes. Otherwise it is refused, naming the waiting request, until that one is approved or rejected: someone who may only change settings cannot discard a pending tool policy change.

Credential bindings

In a tenant whose review-widening is second_admin, or with four eyes on, oz0 tenant credential bind binds nothing at once: it files a change request of kind credential_binding with the binding (the secret's name, the host or argument, and where the secret goes: the header or query parameter, its format, the methods and paths it covers; never a value), which another admin approves; the binding is then the requester's, and the audit entry names the approver. A connection's token binding goes the same way. In a confirm tenant a binding applies at once, as before.