The auto-remediation allowlist: auto, guided, advisory

THE AUTO-REMEDIATION ALLOWLIST:

  ON THE ALLOWLIST, AUTO (26, one-click Apply):
    Listed by rule id in the allowlist table
    Still subject to the per-resource safety gate

  ON THE ALLOWLIST, GUIDED (87, type-to-confirm):
    Same table, plus a human confirmation step

  NOT ON THE ALLOWLIST (advisory, manual execution):
    Remediation steps shown
    Apply button NOT shown
    Customer executes manually

THE ALLOWLIST IN CODE:

  ONE TABLE, TWO COPIES
    The recommender reads it to decide whether
    a rule gets an Apply button
    The provisioner reads it to know which action
    step to run
    The two copies must be byte-for-byte identical

  ENFORCED BY A TEST
    A test compares the two copies and fails the
    build if they drift
    Other tests check the auto and guided counts
    and catch duplicate rule ids

  ADDING OR REMOVING A RULE
    One edit to the table, made identically in
    both copies

TWO TIERS:

  TIER 1  allowlist         "does this RULE support auto?"
                            keyed on rule id, nothing else

  TIER 2  safety gate       "is it safe on THIS resource?"
                            reads authoritative control-plane
                            fields on the recommendation, never
                            tags and never name tokens

  Tier 2 disagrees -> the recommendation is DEMOTED to advisory.
  It is still shown. Nothing is suppressed.

one-shot stop of compute      always demoted. The workload inside a
                              generic instance is opaque to every
                              cloud API, so "this is not a bastion"
                              can never be proven. The finding
                              shows How to Fix steps instead.

delete of a stateful resource demoted. Managed database types, a
                              non-empty engine field, or a data tier.

delete without proof          demoted unless an authoritative field
                              proves the thing is unused:
                                an elastic IP explicitly not
                                associated
                                a volume flagged unattached with a
                                real detach time at least 7 days old
                                a snapshot whose source is provably
                                gone
                                a backup vault with zero protected
                                items

resize needing a stop         demoted on a stateful resource.

AUTO (one-click), illustrative:
  RC-016   Unassociated Elastic IP release (evidence: not associated)
  RC-112 / RC-212   Unattached GCP / Azure disk delete (evidence: detach time)
  RC-003   EC2 rightsizing (resize with a stop; demoted on stateful resources)
  RC-002   Orphan EBS volume delete: on the list, but the safety gate demotes
           it to advisory today because AWS gives no real detach time

GUIDED (type-to-confirm), illustrative:
  RC-021   Orphan EBS snapshot delete (irreversible, so human-confirmed)
  Single-replica K8s bump 1->2 (RC-1706 / 1806 / 1906)
  RC-214   Azure Hybrid Benefit (a reversible licensing setting)
  Pause services: Synapse SQL Pool, Data Factory, ML Compute, Cognitive
           Services, Databricks cluster, GCP Dataproc

NOT auto-remediable (advisory only):
  RC-001   Idle EC2: advisory. It fires on already-stopped instances and
           recommends termination; it is explicitly OFF the allowlist.
  Compliance, network, and IAM changes

ADVISORY RULE CARD example: RC-001 Idle EC2 (stopped 30+ days)
─────────────────────────────────────────────────────────
RC-001 · Idle EC2
[no Apply button]

REMEDIATION (manual)
1. Confirm nobody needs the stopped instance
2. Snapshot any attached EBS volumes you want to keep
3. Terminate the instance and release its Elastic IP
4. Delete the volumes you no longer need

[Console URL: https://us-east-1.console.aws.amazon.com/ec2/...]
[Dismiss] [Mark Resolved]

IF YOUR TEAM WANTS A RULE ALLOWLISTED:
  Raise it with ZopDev support
  An addition is a code change to the allowlist
  table, so there is no self-serve request

WHAT AN ADDITION DOES NOT CHANGE:
  The per-recommendation safety gate still
  re-decides on every resource
  No snapshot is taken before a delete; the
  action is the plain cloud API call (see L1)

UNCERTIFIED rule isn't "unsafe to apply"
  Just hasn't passed ZopNight's bar for one-click execution
  The remediation is still shown
  Customer executes manually with full context

COMMON UNCERTIFIED CATEGORIES:
  Rightsizing outside the allowlisted resize rules
    Risk: workload-specific; needs validation
    Reason: tested only in narrow workloads

  Compliance configuration changes
    Risk: policy interpretation varies
    Reason: customer policy varies

  Network changes
    Risk: high blast radius
    Reason: cross-team dependencies

  IAM changes
    Risk: lockout potential
    Reason: hard to test without breaking

DEFAULT for ALL ALLOWLISTED rules:
  Enabled for every org from day one
  No setup, no opt-in, no per-rule toggle page

THE PER-RULE, PER-ORG FLAG:
  A kill-switch, not an opt-in
  No flag set means the rule is enabled
  Set only by ZopNight through an internal
  endpoint; there is no customer settings page

WHY A KILL-SWITCH:
  A brand-new org needs no setup
  A rule can be switched off for one org
  if it misbehaves there
  If you need that, raise it with ZopNight support

INITIATOR ROLE    WHAT HAPPENS ON REMEDIATE
──────────────────────────────────────────────────────────
Admin             Runs straight through. No approval step:
                  the admin's click is the approval.

Editor            Waits for an admin. Deletes, resizes,
                  pauses and K8s manifest edits add an
                  "Awaiting admin approval" step.

Viewer            Cannot start a remediation at all.
                  Sees the recommendation and its steps.

STARTING POINT:
  Every allowlisted rule already enabled (default)
  Recommendations page shows Remediate on the
  cards the safety gate has not demoted
  Advisory ones show "How to Fix" steps in the
  drawer instead

DECISION 1: WHO IS ADMIN
  2 platform leads hold the admin role
  Their Remediate clicks run with no approval step
  Reason: they already own production change approval

DECISION 2: WHO IS EDITOR
  12 service owners hold the editor role
  They can start remediations on their resources
  Each destructive click waits for one of the 2 admins
  Two admins means an approval never waits on
  one person's calendar

DECISION 3: EVERYONE ELSE
  Viewer role: reads recommendations and evidence,
  cannot start a remediation

DECISION 4: ADVISORY WORK
  RC-001 idle stopped EC2 is advisory (off the list)
  Service owners follow the "How to Fix" steps by hand
  and mark the recommendation resolved

AFTER A MONTH:
  One allowlisted rule misbehaved on an unusual
  resource shape in their account
  They asked ZopNight support to switch that one rule
  off for their org while it was investigated
  Every other rule stayed on

□ STEP 1: List your org's admins
  Count: _____
  Each admin's Remediate click runs without approval.
  Is that right for every one of them? □ Yes □ No

□ STEP 2: List your editors
  Count: _____
  Their destructive clicks wait for an admin.
  Is there more than one admin to approve them? □ Yes □ No

□ STEP 3: Open the Recommendations page
  Pick 3 cards: which show Remediate, which are advisory?
    RC-_____: □ Remediate □ advisory
    RC-_____: □ Remediate □ advisory
    RC-_____: □ Remediate □ advisory

□ STEP 4: Note any rule you want switched off
  Rule: RC-_____   Reason: __________
  (Raise with ZopNight support; there is no self-serve toggle)

□ STEP 5: Set a quarterly role review
  Date: __________
  Owner: __________