Cloud permissions

Discovery, recommendations, cost tracking, and metrics all work with the read permissions on this page. Read + Write features (start/stop, auto-remediation, autoscaler write mode) need the additional permissions you grant explicitly per cloud account. Grant only what the account’s permission level needs, then use View Permissions to confirm every feature is working.

Settings → Cloud Accounts → View Permissions: features that need more access listed above the working ones, with the exact permission behind every row.

Before you start

• A cloud account, connected or about to be. You choose each account’s permission level, Read-only or Read + Write, when you connect it; see Cloud accounts.
• Rights to edit IAM on the provider side: attach policies to the AWS role or user, assign roles on the Azure subscription and billing scope, or bind roles on the GCP project.

How it works

Each cloud needs up to four sets of permissions. The first three are read-only; the fourth is opt-in and only matters on a Read + Write account.

How far back metrics are read

Once the read permissions are in place, ZopNight pulls metrics on a daily cycle. How much history it asks for is set per cloud, matched to what each provider actually retains, so a request never silently returns nothing:

Individual rules can ask for a shorter window than their cloud’s default, and none ask for a longer one. Keep this in mind when you read a finding’s evidence: a rule quoting a 30-day average on GCP is working from the same data you can see in Cloud Monitoring.

AWS: IAM policies

ZopNight pulls CloudWatch metrics and EBS/EC2 resource shapes with the policy below. Attach this policy to the IAM user or role you give ZopNight.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchRead",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:GetMetricData",
        "cloudwatch:ListMetrics"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2DescribeForResourceShape",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:DescribeInstances",
        "ec2:DescribeRegions"
      ],
      "Resource": "*"
    }
  ]
}

Namespaces ZopNight queries

The CloudWatch policy lets ZopNight read metrics in these namespaces:

AWS/EC2, AWS/EBS, AWS/RDS, AWS/Lambda, AWS/ElastiCache, AWS/MemoryDB, AWS/Redshift, AWS/OpenSearchService, AWS/DynamoDB, AWS/DocDB, AWS/Neptune, AWS/SQS, AWS/SNS, AWS/CloudFront, AWS/NATGateway, AWS/TransitGateway, AWS/Kafka, AWS/Kinesis, AWS/SageMaker, AWS/Bedrock, AWS/ElasticMapReduce, AWS/AppStream, AWS/WorkSpaces, AWS/ApiGateway, AWS/EFS, AWS/ApplicationELB, AWS/NetworkELB, AWS/EC2/Spot, AWS/S3-RequestMetrics.

Discovery permissions

The policy above covers metrics. Discovery uses Resource Explorer 2 plus per-service describe calls. For the full discoverer permission set, the simplest path is to attach the AWS-managed ReadOnlyAccess policy on top of the metrics policy above.

Billing data (for actual cost in Reports)

To replace rack-rate calculation with real billing cost in Reports, ZopNight needs AWS Cost Explorer access. Attach this policy in addition to the above:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ce:GetCostAndUsage",
      "ce:GetCostAndUsageWithResources",
      "ce:GetTags"
    ],
    "Resource": "*"
  }]
}

Cost is chosen per resource per day: a resource-day with a billing row uses billed cost, and one without falls back to rack rate, in the same organisation and the same report. An account without this policy therefore shows rack rate while your other accounts show billed cost.

Start / Stop (opt-in)

For ZopNight to stop and start resources via schedules, autoscaler, or auto-remediation, you need the corresponding action permissions per service. For EC2 start/stop, attach this policy in addition to the read policies above:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:StartInstances",
      "ec2:StopInstances"
    ],
    "Resource": "*"
  }]
}

Other services follow the same shape (rds:StopDBInstance, rds:StartDBInstance, and so on). Contact support for the full per-service write policy template.

Azure: Service Principal role assignments

When using the Service Principal method, ZopNight authenticates with clientId / clientSecret / tenantId / subscriptionId. Workload Identity Federation is also supported. Whichever Azure auth method you pick, the minimum role assignment is:

Role:    Monitoring Reader
Scope:   /subscriptions/{subscriptionId}

Monitoring Reader includes Microsoft.Insights/metrics/read on every resource in the subscription, which ZopNight needs to read Azure Monitor metrics such as disk queue depth and latency.

Billing data

Azure billing data uses the Cost Management Reader role on the billing scope. ZopNight reads amortised cost, so reservation and savings-plan purchases are spread across their term and attribute correctly per resource per day. Actual cost at subscription scope would show reserved VMs at $0.

Start / Stop / deallocate (opt-in)

For VM lifecycle actions, ZopNight needs Microsoft.Compute/virtualMachines/start/action, /restart/action, and /deallocate/action. The Virtual Machine Contributor built-in role covers these. For AKS scaling, add Azure Kubernetes Service Cluster User Role and Azure Kubernetes Service Contributor Role.

GCP: Service Account roles

For the Service Account Key method, ZopNight authenticates with a service-account JSON; One-Click Connect uses a managed service account instead. Whichever auth method you pick, the minimum role is:

Role:    roles/monitoring.viewer
Scope:   project (the GCP project that owns the resources)

This includes monitoring.timeSeries.list, which ZopNight uses to read Cloud Monitoring metrics such as disk latencies and throttled operations, and the metrics for Cloud Storage, Pub/Sub, load balancers, and Cloud SQL.

Cloud Asset Inventory (for discovery)

Add roles/cloudasset.viewer for resource discovery. It powers the Cloud Asset Inventory sweep that discovers the 70 GCP resource types ZopNight supports.

Billing data

For real billing cost in Reports, ZopNight reads from BigQuery billing exports. Add roles/bigquery.dataViewer and roles/bigquery.jobUser on the billing project, plus the billing export configured at the GCP organisation level. Contact support for the BigQuery dataset configuration.

Start / Stop (opt-in)

Compute Engine lifecycle actions need roles/compute.instanceAdmin.v1. GKE needs roles/container.developer (or container.admin for namespace operations).

IAM Import (optional)

To pull GCP IAM members and bindings for the Cloud IAM Import wizard, grant roles/iam.securityReviewer. To also pull Google Group members, grant roles/cloudidentity.groups.reader at the organisation level (not project level).

Check permissions per account

After you connect an account, ZopNight records which permissions each feature can use. Settings → Cloud Accounts → View Permissions opens a drawer grouped by feature, with a count of the features that need more access and the ones that are working, and the status of every permission behind each feature (see the screenshot above).

Denied entries auto-skip in the periodic 6-hour discovery cron for 24 hours, so a permission gap doesn’t cost you repeated failed API calls. A manual refresh always retries everything.

Metric coverage check

1. Grant the missing role

   Use the permission the drawer names for the feature that needs more access.

2. Refresh the account

   Trigger a manual refresh from the cloud account to pick up the newly allowed resource types immediately.

3. Confirm

   Reopen View Permissions and check that the feature has moved from needing access to working.

Troubleshooting

Next steps