Read-Only Access Requirements
This page describes everything Cloudchipr needs from your cloud environments in read-only mode, so your security and platform teams can review the access model and stage the required roles before anyone opens the product.
Read-only is the recommended starting mode. It supports the full cost and optimization product: visibility, Billing Explorer, dashboards, inventory, utilization metrics, recommendations, budgets, and alerts. It cannot create, modify, or delete anything in your environment.
Principles
The access model is the same across every provider:
- Read-only. The access described on this page cannot create, modify, or delete anything in your environment.
- No access keys or secrets. Cloudchipr does not use AWS access keys, GCP service account key files, or Azure client secrets. Connections use role-based access control: you grant a role to an identity, and no long-lived credential of yours is shared. Databricks and Snowflake are the exceptions, and are covered in the table below.
- Agentless, except Kubernetes. Nothing is installed inside your resources. Cloudchipr reads through the provider's own APIs. In-cluster Kubernetes monitoring is the one case where an agent runs in your environment, and it is deployed by you via Helm.
- You grant it, you revoke it. Every permission is assigned by your own administrators, appears in your own audit logs, and can be removed at any time without involving Cloudchipr.
What read-only access requires, by platform
| Platform | Identity Cloudchipr uses | Read-only grant | Scope | Authentication | Admin needed to set up |
|---|---|---|---|---|---|
| AWS | An IAM role in your account, assumed cross-account by Cloudchipr | Read-only IAM role created by the read.json CloudFormation stack, plus CloudchiprAccountReadAccessRole in member accounts | Organization payer account, or a single standalone account | sts:AssumeRole with a connection-specific sts:ExternalId. No access keys are created or stored | IAM admin on the payer account |
| GCP | A Cloudchipr-owned Google service account, granted roles in your organization | Viewer, plus Organization Role Viewer and Browser at organization scope | Organization (recommended) or a single project | IAM policy binding. No service account key file is exported | Organization Administrator, or Project IAM Admin |
| Azure | A Cloudchipr application identity, instantiated as a service principal in your tenant | Reader, plus Storage Blob Data Reader on a single dedicated storage account holding the billing export | Reader at a management group or chosen subscriptions. The blob role at one storage account only | Microsoft Entra ID service principal | Owner, or User Access Administrator |
| Databricks | An account-level service principal that you create | USE CATALOG / USE SCHEMA / SELECT on nine Unity Catalog system tables, plus the USER workspace role | Databricks account, and one workspace | OAuth client ID and secret, issued by you to the service principal | Account Admin, and Metastore Admin |
| Kubernetes | An in-cluster agent you install via Helm | Read access defined by the Cloudchipr Helm chart | Per cluster | Cloudchipr API key | Cluster admin, Helm v3 |
| Snowflake | A role and warehouse created by the Cloudchipr setup script | The read-only role created by that script | Snowflake account | Account identifier and storage integration | ACCOUNTADMIN |
What is collected, and what is not
Cloudchipr needs to know two things: what you run and how heavily it is used, and what it costs. It reads the shape of your infrastructure, not the contents.
The list below describes what the Cloudchipr platform reads. Where the underlying provider grant is broader than that list, it is documented on the per-cloud page, so you can assess the grant and the product behaviour separately.
Collected (read-only)
- Resource inventory and configuration: type, size, region, tags, and running state of each resource
- Utilization metrics: CPU, memory, disk, and network usage over time
- Billing and cost data: cost and usage line items from your provider bill. On AWS this is a Cost and Usage Report or Data Export; on Azure it is a Cost Management Export written to one dedicated storage account; on GCP it is your billing data
Not accessed
- Storage contents: no files, objects, or backups are opened. The one deliberate exception is Azure, where Cloudchipr reads the cost and usage files in a single dedicated storage account you create solely for the billing export, and cannot reach any other storage account in your tenant
- Database contents: no rows, tables, or query results
- Secrets: no Key Vault, Secrets Manager, or Secret Manager material, keys, or certificates
- Inside compute: no disk contents, memory, or running application data
- Personal or health information (PII / PHI): none is seen or stored
- Credentials: no access to your users, logins, or application accounts
See Security & Compliance for certifications and the wider security program.
Revoking access
Access ends the moment you remove the grant. No coordination with Cloudchipr is required.
| Platform | How to revoke |
|---|---|
| AWS | Delete the Cloudchipr CloudFormation stack, and the CloudchiprAccountReadAccessRole roles in member accounts |
| GCP | Remove the IAM policy binding for the Cloudchipr service account at the organization or project |
| Azure | Remove the two role assignments, or delete the Cloudchipr enterprise application from your tenant |
| Databricks | Delete the service principal. This removes its workspace assignment and every system table grant |
| Kubernetes | Uninstall the Helm release, and revoke the API key |
| Snowflake | Drop the role created by the setup script |
Updated about 5 hours ago