What "read-only" should mean

Many tools say they are read-only. The word is only useful if you can check it. A scan that is really read-only has four properties:

  • No write permission. The account it uses cannot create, change or delete anything in your project.
  • No data access. It can see that a bucket or a database exists, and how it is configured, but not what is inside.
  • No long-lived key. Access comes from a short-lived token, not from a key file that someone can copy and forget.
  • It lives in your project. The account is created in your own project, so you can see it, change it and remove it.

This is how reCloud, our cloud waste scanner, is built: one read-only account in your own Google Cloud project, no key file, and a token that lasts one hour.

What a scan can see

To find waste and risk, a scan only needs to know how your cloud is set up. In practice that means:

  • which disks, virtual machines, IP addresses, snapshots, databases and load balancers exist, and where;
  • how each one is configured: size, status, whether it is attached to anything, whether it is open to the internet;
  • the labels on each resource, which show who owns it;
  • which identities exist and which roles they hold.

With that you can answer the useful questions: is it still used, who owns it, is it safe to delete, and what should be fixed first. See nine zombie resources in your Google Cloud bill for what those findings look like.

What stays closed

The things you care about most should be out of reach by design:

  • files stored in buckets;
  • rows inside databases;
  • secrets and keys held in a secret manager;
  • anything that would let the scanner act, such as deleting a resource.

The same rule applies to the findings. A good scanner shows you the command that would remove a zombie resource, and you run it yourself. It never runs it for you. Our own advice for the clean-up step is in how to delete cloud resources without breaking production.

Questions for your security team

Before you connect any scanner, ask for these answers in writing:

  1. What exact role does it use, and can we read the full list of permissions?
  2. Does the role include any permission to read stored data, or to write or delete?
  3. Is a key file created? If so, where is it stored and for how long?
  4. Where does the scan result go, and who can read it?
  5. How do we end access, and how do we check that it ended?

If the answers are vague, treat that as a finding. A tool that wants to understand your cloud should be easy to understand itself.

Ending access

The best control is one you can use yourself. With a read-only account in your own project, you end access by deleting that account, and you can confirm it in your project's own access list. Nothing depends on the vendor to switch it off.

reCloud is in early access for Google Cloud, with AWS and Azure next. You can see how it works or start with the free scan plan, and your security team can review the role before anything is connected.