Read-only safety: where it matters, where it doesn't

Outcome

By the end of this lesson, you will be able to explain the read-only safety model and identify which CDCR operations cross the read-only line.

1. Concept

A system that can change your cloud invites three fair questions. What is it actually able to do? What access does that need? And how safe is it?

The answer is that nearly everything it does is reading, and the few things it can change are each narrowed to one specific action. Layer by layer:

LAYER                                  PERMISSIONS NEEDED
─────────────────────────────────────────────────────────────────
1. Discovery (resource inventory)      Read-only across providers
2. Metrics ingestion                   Read-only (CloudWatch, Cloud Monitoring)
3. Activity log sync                   Read-only (CloudTrail, Cloud Logging)
4. Recommendation generation           Read-only (uses 1-3 as input)
5. Cost reporting                      Read-only (billing data + pricing API)
6. Schedule execution                  Scoped write (start / stop only)
7. Auto-remediation (idle / orphan)    Scoped write (terminate specific resources)
8. Autoscaler policy management        Scoped write (specific policy types)
9. Database mutations                  NEVER. Hard-blocked in code.

The first five layers only read. That is most of what the system does. Layers 6 to 8 can change things, within strict limits. Layer 9 is off the table: the system will not change a customer database, ever.

What a scoped write is

Three things make a write scoped rather than open-ended.

1. It does exactly one thing. Start a machine. Stop a machine. Delete one specific unattached disk. Apply one specific scaling policy. It cannot reach past that, even when the cloud credentials it holds would allow more.
2. It leaves a record. Every change is written to the audit log with the request and the response, so you can ask what was done, when, to which resource, and with what result.
3. You switch it on. Automatic fixing is off by default for most rules. The default behaviour is to show you the recommendation and wait.

The database list

Layer 9 is worth dwelling on. The system never changes a customer database, whatever a rule might recommend. The list is written into the code:

Resource types that NEVER auto-mutate:
  rds*, aurora*, cloudsql*, elasticache*, azure-sql*,
  postgres*, mysql*, dynamodb*, cosmos*, mongodb*,
  redshift*, snowflake*, databricks-data*

Action types that NEVER auto-execute on the above:
  modify, delete, scale, change-tier, change-class,
  enable-encryption, change-multi-az

A recommendation to move an RDS instance from db.r5.4xlarge down to db.r5.2xlarge is shown to you, and stops there. You make that change yourself, in the AWS console, in a maintenance window you chose. The system will not do it for you.

Why so cautious about databases? Because a bad database change means corrupted data, lost data or an outage, and any of those costs far more than the saving was worth. This University teaches it as a rule with no exceptions: saving money never comes at the expense of the data being correct.

Asking for as little access as possible

The credentials ZopNight asks for are trimmed to what each layer actually needs. When you connect an account it suggests:

• AWS: A read-mostly role with scoped permissions per service, with optional :Action extensions for the scoped writes.
• GCP: A service account with roles/viewer plus narrow custom roles for the scoped writes.
• Azure: A service principal with Reader plus optional Contributor scoped to the resource groups the customer wants ZopNight to manage.

You can refuse any of the write permissions. Nothing breaks: the feature that needed it shows as “monitor only” rather than fully active. Finding resources carries on. Recommendations carry on. Only the acting is switched off.

Seeing what it was allowed to do

The system shows you its own access. Each cloud account has a Permission Visibility drawer, which is a panel that slides out from the side of the page.

It marks every provider, resource type and region as Granted, Denied or Unknown. Anything refused shows the exact error the cloud gave back.

That matters more than it sounds. Most tools fail a scan quietly and simply report a smaller estate, which looks like good news and is not. ZopNight would rather tell you the number is incomplete. T1.M1.1 goes through the drawer in detail.

The approval gate

Some changes can be undone but are still worth a second pair of eyes, such as terminating a machine in a test environment. For those the system waits for approval. A named admin gets the request in Slack or by email, looks at it, and approves or declines. Only then does anything happen.

The approval gate is:

• Default for most write paths (especially anything destructive)
• Configurable per rule (some rules can be moved to auto for environments the customer trusts)
• Logged in the audit trail (who approved what, when)
• Skippable for the low-risk cases, such as a schedule starting and stopping tagged non-production machines

How this passes security review

A Security review of CDCR typically asks five questions. The model’s answers:

1. “What can the tool see?” → Read-only across the configured providers. Permission Visibility shows exactly what was scanned.
2. “What can the tool do?” → Only the scoped writes the customer enabled. Database mutations are categorically blocked.
3. “How is access audited?” → Every mutating call to the gateway is logged with request+response capture.
4. “How is access controlled?” → Automatic fixing is switched on one rule at a time. Anything destructive waits for approval. People hold one of three roles, and the role decides what they may do.
5. “What is the blast radius of a compromised ZopNight credential?” Blast radius means everything that would be affected if this went wrong. → The IAM credentials are scoped. The worst case is the scoped-write surface, audit-logged, with approval gates on destructive ops.

Those answers hold up because the design started from that review rather than being bolted on afterwards.

2. Demo

A live look at the safety model for one rule:

RULE: RC-001 Idle EC2
─────────────────────────────────────────────────────────
Detection: read-only, uses CloudWatch CPU + state history
Classification: idle, non-prod, no DB attachment, has snapshot
Default action: SHOW THE RECOMMENDATION
Auto-remediation toggle: OFF by default
                          ON enables the action path

WHEN AUTO IS ON:
  Pre-check: confirm no override active
  Pre-check: confirm not in database denylist
  Pre-check: confirm tags match customer-defined eligibility
  Action: snapshot EBS, terminate instance, terminate EBS
  Post-check: verify termination, confirm savings landed in billing
  Audit log: full request+response captured

CUSTOMER CAN AT ANY TIME:
  - Turn off auto for this rule
  - Add a per-resource exclusion
  - Move this rule to approval-gated
  - Pause all auto-remediation org-wide

The customer is in control at every layer. The system’s defaults are conservative; the customer opts in to more aggressive automation as they build trust.

3. Hands-on (6 min)

For your own deployment (or as a thought exercise on a proposed CDCR rollout):

1. Which scoped writes do you want to enable?
   - Schedule start/stop (compute):       Y / N
   - Schedule start/stop (K8s workloads):  Y / N
   - Auto-terminate orphan storage:        Y / N
   - Autoscaler policy management:         Y / N

2. For each "Y," what's the approval-gate posture?
   - Auto for non-prod, approval for prod
   - Always approval-gated
   - Auto always (most aggressive)

3. Who is the designated approver?
   Name: __________
   Backup approver: __________
   Approval SLA: __________ hours

4. What's the org-wide kill switch?
   Where is it: ____________
   Who can trigger it: ____________

If any answer is blank, the rollout has a gap. Close the gaps before
auto-remediation is enabled.

4. Knowledge check

Q1

A Security reviewer asks: “Can ZopNight modify our customer database?” The most accurate answer is:

A. Yes, if auto-remediation is enabled
B. Only with approval
C. Only for non-prod databases
D. No

Q2

A team is rolling out CDCR. The Security team requires that all destructive operations go through change management. The compatible configuration is:

A. Disable CDCR
B. Set all destructive-class rules to approval-gated; route approval to the change management system; allow auto on non-destructive scoped writes (schedule start/stop on tagged non-prod)
C. Run ZopNight in monitor-only mode forever, so that it never mutates anything at all and the security team never has to review any write path of any kind or description
D. Custom build

Q3

“Read-only safety” means:

A. The tool only reads, never writes
B. The tool is too cautious to be useful
C. The default posture is read-only
D. Permissions are read-only by AWS policy

5. Apply

ZopNight surfaces the safety model in three places:

• Cloud Accounts → Permission Visibility shows what the credentials allow
• Recommendations → Auto-Remediation toggle per rule lets the customer opt in
• Audit Logs shows every write the system has performed

For a Security review pre-flight: open the Permission Visibility drawer, screenshot it for the Security team. Open the Auto-Remediation panel, show the current state of each rule. Open the Audit Log for the past 30 days, demonstrate the write surface is small and auditable.

Related lessons

• L4: What CDCR is NOT (next: closes the module)
• T1.M1.1: Connect a cloud account
• T3.M3.3: Audit logging

Glossary terms touched

Read-only safety · Scoped write · Database denylist · Approval gate · Permission Visibility