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, databases included)
7. One-click remediation               Scoped write (one action per rule)
8. Autoscaler policy management        Scoped write (specific policy types)
9. Smart Tags "Apply to cloud"         Scoped write (tags only, run on demand
                                       by a person)
10. A fix that stops, deletes or       NEVER. Blocked in code.
    resizes a customer database

The first five layers only read. That is most of what the system does. Layers 6 to 9 can change things, within strict limits. Layer 10 is off the table. A fix never stops, deletes or resizes a database. Schedules can start and stop them. Schedules are a separate feature from fixes: a schedule you create starts and stops resources at the times you set.

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. A person starts it. No fix runs until somebody clicks Remediate. The default behaviour is to show you the recommendation and wait. Findings without a Remediate button are fixed by a person following the How to Fix steps.

The database list

Layer 10 is worth dwelling on. A fix never stops, deletes or resizes a customer database, whatever a rule might recommend. The code works the other way round from a blocklist: it lists the resource types each kind of fix may touch, and databases are not on those lists. The pause step, for example, may only pause six analytics, ML and ETL services, and a test pins the exact list of pausable types:

Never on the list of what a fix may stop, delete or resize:
  RDS, Aurora, Cloud SQL, Azure SQL, ElastiCache, Postgres, MySQL

A few guided fixes do change a database setting without touching its data, such as moving RDS storage from gp2 to gp3 or shortening backup retention. Those need a typed confirmation, like every guided fix.

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: Narrow predefined read roles rather than the broad roles/viewer, plus write permissions for the scoped writes.
• Azure: Reader and Cost Management Reader, plus the custom roles “Zopnight Write Access” and “Zopnight AKS Access” for the scoped writes.

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 are worth a second pair of eyes. Two checks cover that:

• Admin approval. When the person who clicks Remediate is not an admin, the fix waits. An admin gets the request by email, looks at it, and approves or declines. Only then does anything happen. A request nobody answers expires after 48 hours.
• Typed confirmation. Riskier fixes, such as deleting something, are “guided”: before anything runs you review the change and type to confirm it.

Approvals are logged in the audit trail (who approved what, when).

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 granted. A fix runs only when a person clicks Remediate. Smart Tags “Apply to cloud” writes accepted tags to the cloud resources, and only when a person runs it. Schedules, a separate feature, start and stop resources at the times the customer set. No fix stops, deletes or resizes a database.
3. “How is access audited?” → Every mutating call to the gateway is logged with request+response capture.
4. “How is access controlled?” → No fix runs until a person clicks. A non-admin’s fix waits for an admin’s approval, and riskier fixes need a typed confirmation. 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-002 Orphaned EBS Volume
─────────────────────────────────────────────────────────
Detection: read-only, volume unattached ("available") 7+ days,
           not managed by Kubernetes
Classification: orphan, one-click fix
Default action: SHOW THE RECOMMENDATION with a Remediate button

WHEN SOMEONE CLICKS REMEDIATE:
  Precondition: confirm the volume is still unattached
  Approval: if the person is not an admin, wait for an admin
            (the request expires after 48 hours)
  Action: delete the volume
  Validate: confirm the volume is gone
  Record: the run and each of its steps are kept

THE CUSTOMER CAN ALWAYS:
  - Leave the recommendation alone, or dismiss it
  - Do the change by hand instead
  - Decide who is an admin, and so who can approve

Compare RC-001, which flags a server stopped for 30 days or more. It is advice only: no Remediate button, just the steps to do it yourself, because terminating a server is not something the system does for you.

The customer is in control at every layer. Nothing runs until a person decides it should.

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 grant?
   - Schedule start/stop (compute and databases): Y / N
   - Schedule start/stop (K8s namespaces):        Y / N
   - One-click delete of orphan storage:          Y / N
   - Autoscaler policy management:                Y / N

2. Who may click Remediate?
   - Admins only
   - Admins, plus engineers whose fixes wait for an admin

3. Who is the designated approver?
   Name: __________
   Backup approver: __________
   Approval SLA: __________ hours (requests expire after 48)

4. How do you take write access back?
   Which permissions to remove: ____________
   Who can remove them: ____________

If any answer is blank, the rollout has a gap. Close the gaps before
anyone starts clicking Remediate.

4. Knowledge check

Q1

A Security reviewer asks: “Can a ZopNight fix stop, delete or resize our production database?” The most accurate answer is:

A. Yes, once one-click fixes are enabled
B. Only with an admin’s approval
C. Only for non-production databases
D. No

Q2

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

A. Disable CDCR
B. Make the change approvers the admins and give engineers a non-admin role, so every fix an engineer starts waits for an approver
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:

• Settings → Cloud Accounts, in each account’s permissions drawer, shows what the credentials allow
• Recommendations shows which findings carry a Remediate button (fixed in one click) and which are advice only
• 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 Recommendations and show which findings carry a Remediate button and which are advice only. 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
• T4.M4.3: Audit logging

Glossary terms touched

Database protection · Approval gate · Permission visibility