Permission Visibility: what the dashboard tells you

Outcome

By the end of this lesson, you will be able to read the Permission Visibility drawer and act on any Denied entry to restore full discovery.

1. Concept

Most cost tools go quiet when a permission is missing.

The cloud refuses one of their read requests with an AccessDenied, a 403 or an AuthorizationFailed. The tool writes an error into a log nobody reads. Your dashboard shows a number lower than reality, and it looks like good news. Months later an audit finds that a fifth of the estate was never scanned at all.

ZopNight will not do that. Every refusal during a scan is recorded: which cloud, which resource type, which region, and the exact wording of the refusal. All of it appears in the Permission Visibility drawer, which opens from any cloud account through “View Permissions”.

What the drawer shows

ACCOUNT: prod-aws-us-east-1                         Status: Active

CATEGORY               TYPES SCANNED     STATUS
─────────────────────────────────────────────────────────────────
Compute                12 / 12            All Granted
  ec2                  4 regions          Granted   ●
  asg                  4 regions          Granted   ●
  lambda               4 regions          Granted   ●
...

Kubernetes              3 / 3            All Granted
  eks                  4 regions          Granted   ●
...

Database                4 / 5            Partial
  rds                  4 regions          Granted   ●
  aurora               4 regions          Granted   ●
  elasticache          4 regions          Granted   ●
  documentdb           4 regions          Denied    ●  ← see below
  dynamodb             4 regions          Granted   ●

Storage                 3 / 3            All Granted
...

DocumentDB error detail:
  Region: us-east-1
  Error: User: arn:aws:iam::...:assumed-role/ZopNightDiscovery
         is not authorized to perform: docdb:DescribeDBClusters
  Last attempt: 2 hours ago

  ACTION: Add docdb:Describe* to the IAM policy and re-run discovery.
  The CloudFormation template snippet to copy is provided.

The drawer shows:

• Coverage at category level (Compute, Kubernetes, Database, Storage, etc.)
• Granted / Denied / Unknown badge per resource type per region
• Exact error message for any Denied entry (with the calling principal and the missing action)
• Last attempt timestamp so the user knows how recent the failure is
• Action guidance to fix the gap

The three states

• Granted (green). In the last 24 hours, at least one read of this resource type in this region worked.
• Denied (red). The read was attempted and the cloud refused it, with an AccessDenied, a 403 or an AuthorizationFailed. The drawer prints the refusal word for word.
• Unknown (grey). Nothing has been tried yet, or the cloud gave an answer that settles neither way. The usual cause is a region you enabled recently, and the next scan will turn it green or red.

How often each one is retried

Scans run every 6 hours, and not everything is retried at the same rate.

• Green entries are tried again on every scan, roughly every 6 hours
• Red entries are left alone for 24 hours. Asking again every 6 hours wastes time, and permissions rarely change that quickly
• A manual refresh retries everything, red ones included. That is the button to use the moment you grant a missing permission, so you are not waiting a day to see whether it worked

The result is that ordinary scans stay quick, and you can still get an answer in a minute when you want one.

How to fix a Denied entry

A typical fix loop:

1. Open Cloud Accounts → click the account → View Permissions
2. Scroll to Denied entries, expand one
3. Read the error: "not authorized to perform: docdb:DescribeDBClusters"
4. The drawer offers a CloudFormation template snippet adding the missing action
5. Apply the snippet to your role, however you manage it
6. Wait ~30 seconds for the change to take effect across AWS
7. Click "Manual refresh" in ZopNight Cloud Accounts page
8. Wait ~60 seconds for the discovery to re-attempt
9. Refresh the Permission Visibility drawer
10. The previously-Denied entry should now show Granted

Five minutes from spotting the gap to closing it.

Why this matters beyond convenience

Three operational uses:

1. Proving your monitoring is complete. A SOC 2 or ISO 27001 audit asks which cloud resources your monitoring actually covers. This drawer answers it precisely: every category granted, nothing denied. The auditor can open it and see the same thing you did.

2. Buying another company. When you acquire a business, what you most need to know is which parts of their cloud nobody was watching. The drawer tells you in minutes, where working it out by hand takes weeks.

3. Explaining a gap against the invoice. When the ZopNight monthly report and the cloud bill differ by 8 percent, this drawer is the first place to look. If 8 percent of the estate was never scanned, you have your answer.

2. Demo

A common scenario, walked through:

Day 1, Morning:
  Customer connects AWS account with the baseline IAM policy.
  Discovery runs. Permission Visibility drawer shows mostly Granted,
  except DocumentDB (Denied: the customer didn't include docdb:* in policy).

Day 1, Afternoon:
  Customer notices DocumentDB Denied. Reads the error in the drawer.
  Copies the CloudFormation snippet ZopNight offers (adds docdb:Describe*).
  Applies it via CloudFormation.

Day 1, Afternoon + 5 min:
  Customer clicks "Manual refresh" in ZopNight.
  Discovery re-attempts DocumentDB. Returns Granted.
  Permission Visibility shows All Granted.

Day 1, Afternoon + 6 hr:
  First scheduled discovery sync after the manual refresh.
  Discovery picks up 4 DocumentDB clusters that were invisible before.
  Recommendation engine fires for one of them (RC-193: idle DocumentDB).
  $1,840/month potential savings now exposed.

PRE-FIX:   Estate coverage: 87%, missing $1,840/mo savings
POST-FIX:  Estate coverage: 100%, $1,840/mo recommendation surfaced

The 5-minute permission fix unblocked $22,080/year of savings that was structurally hidden.

3. Hands-on (5 min)

For one of your connected accounts:

1. Open Cloud Accounts → click the account → View Permissions.
2. Scroll the drawer top to bottom. Note any Denied entries.
3. For each Denied entry:
   - Read the error
   - Note which resource type and region
   - Estimate how much hidden spend might live there (best guess)
4. If any Denied is in a high-spend category (compute, database, storage):
   - Apply the suggested IAM extension
   - Click Manual refresh
   - Verify Granted within 5 minutes
5. If all Denied entries are in low-spend / unused categories: document
   them and accept the gap.

The goal is to know the coverage state, not to close every gap. A team that knowingly excludes a service is far better off than one that doesn’t know it has a gap.

Why this part is console only. Connecting a cloud account is done in the console. There is no way to do it from an assistant, by design: connecting hands over credentials, and that stays a deliberate human step.

Once it is connected, an assistant can read it for you: which accounts are wired up, and exactly what each one is permitted to see. Ask “which accounts are connected and what can we read on each” and you get the table you are looking at now, without opening the console.

Tools that read it afterwards: list_cloud_accounts (read, Explore), get_cloud_account (read, Explore), get_cloud_account_permissions (read, Govern). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

A team’s ZopNight monthly cost report is 8% lower than their AWS invoice. The first thing to check is:

A. ZopNight is broken
B. Currency conversion
C. The Permission Visibility drawer
D. The AWS invoice itself is wrong

Q2

A new region is enabled in the customer’s AWS account. The Permission Visibility drawer shows the new region as Unknown for several resource types. The cause:

A. ZopNight is failing
B. The 6-hour discovery cron hasn’t run since the region was enabled
C. The region is unsupported
D. The credential has become invalid since the region opened

Q3

A SOC 2 auditor asks for evidence of “complete cloud inventory coverage.” Most defensible response:

A. Run a Python script
B. Refer the auditor to AWS
C. Manually count the resources and hand-build a spreadsheet for the auditor to review
D. Screenshot the Permission Visibility drawer showing All Granted across all categories

5. Apply

The Permission Visibility surface is:

• Cloud Accounts → click any account → View Permissions: the main entry point
• Daily summary email can include any Denied changes since the last day
• Audit Log records permission state transitions (e.g., Denied → Granted after a customer fix)

For new connections, the recommended first check is the drawer immediately after connection. Catching gaps on day one is much cheaper than discovering them in an audit on day 180.

Module quiz

You have now completed all four lessons of M1.1. The module quiz (10 questions, 80% pass) is on the Operator certification page.

Related lessons

• M1.2: Discover your estate (next module)
• T3.M3.3: Audit logging

Glossary terms touched

Permission Visibility · Granted / Denied / Unknown · Manual refresh · Coverage