The access model
CoverOps works through a role you create in your own account. Here is exactly what that role is, and what it can and cannot do.
The role you create
CoverOps does not host your workloads. It operates on your infrastructure through a role you create inside your own AWS, Azure, GCP, DigitalOcean or Oracle Cloud account, from a policy CoverOps generates for you as Terraform, CloudFormation or a CLI script: an IAM role with an external ID on AWS, a service principal with the Reader role on Azure, a viewer service account on GCP, a custom-scoped read token on DigitalOcean, or an API key on a read-only group in Oracle Cloud. The default is read-only.
On AWS we store no access keys at all: each sync assumes your role and gets short-lived credentials that expire on their own. On Azure, GCP, DigitalOcean and Oracle Cloud the secret, key or token is encrypted at rest with AES-256-GCM and used only by sync jobs. Either way the delegation lives in your account and you can revoke it at any moment.
What the role is permitted to do
- Read your resource inventory, CPU utilisation and cost, in order to price waste
- On AWS, with the write access you granted: stop an idle instance, rightsize an instance, snapshot and delete an unattached volume, each raised as a proposal
- Apply a proposal only after a named person approves it, and roll it back on request
- On Azure, GCP, DigitalOcean and Oracle Cloud: read only; fixes are advice you apply yourself
What it is not permitted to do
- Hold root or owner credentials for your cloud account
- Change a resource you have not tagged
coverops:managed=true - Read application data, database contents, or object storage payloads
- Create new identities or widen its own permissions
- Continue operating after you revoke the role
To end access, see revoking access. For logging, the data we hold and how to report a vulnerability, see the security overview.