Skip to main content

​
How Amnify authenticates

Amnify connects to Google Cloud with a service account that you create in your own project. You grant that service account read-only roles, create a JSON key for it, and provide that key to Amnify. Amnify stores the key encrypted (AES-256-GCM) and uses it only at scan time to authenticate to Google and read your resource configuration. Every scan runs as the service account you created — access is scoped to exactly the roles you grant it, and you can revoke it at any time by deleting the key or the service account.

​
Steps to connect

1

Create a service account

In the Google Cloud console, go to IAM & Admin → Service Accounts for the project you want scanned and click Create service account. Give it a recognizable name (for example amnify-scanner) so it’s clear later what it’s for. You do not need to grant it any access on the “Grant this service account access to project” step here — you’ll assign roles in the next step. Finish creating the account.
2

Grant the service account read-only roles

Go to IAM & Admin → IAM, click Grant access, and add the service account you just created (its email ends in .iam.gserviceaccount.com) as a principal. Grant it two roles:
  • Viewer (roles/viewer)
  • Security Reviewer (roles/iam.securityReviewer)
Do this on each project you want assessed, or grant the roles once at the folder or organization level to cover many projects at once. The service account only needs read access to the projects Amnify should scan.
3

Create a JSON key

Open the service account under IAM & Admin → Service Accounts, go to the Keys tab, and choose Add key → Create new key. Select JSON and click Create. Google downloads a JSON key file to your machine. Keep this file secure — it is a credential for the service account.
4

Provide the key to Amnify

In Amnify, click Connect GCP. Paste the contents of the JSON key file into the Service account JSON field, or use Upload JSON to select the downloaded file, then click Save connection. Amnify validates the key, encrypts it, and uses it to discover the projects the service account can see.
5

Select the projects to scan

Amnify lists the projects the service account can access. Toggle on the ones where you granted the roles in Step 2. Each selected project is scanned individually as the service account.

​
Tier 1: Project read access (required)

What: the two predefined read-only roles granted in Step 2, on each project (or on a folder or organization):
  • roles/viewer — read-only visibility into resource configuration.
  • roles/iam.securityReviewer — read IAM policies (who can access what), which the posture checks need and roles/viewer alone does not fully cover.
Why: Posture assessment inspects how your resources are configured — networking, storage, compute, databases, IAM bindings, and logging settings — to flag insecure settings. Both roles are read-only: they grant no ability to change, create, or delete resources, and no access to the data held inside them, such as Cloud Storage object contents, database rows, or Secret Manager values. This is the only tier GCP requires. Unlike Azure, there is no separate directory or identity tier — reading IAM policies is already covered by roles/iam.securityReviewer, and Amnify requests no Cloud Identity or Google Workspace directory access.

​
How the key is stored and revoked

  • The JSON key you provide is encrypted at rest (AES-256-GCM) and decrypted only in memory at scan time to obtain a short-lived Google access token. It is never returned to the UI after you save it.
  • To rotate the credential, create a new JSON key in the Google Cloud console, reconnect it in Amnify, and delete the old key.
  • To revoke access entirely, delete the service account’s key (or the service account itself) in the Google Cloud console, or remove the connection in Amnify. Either action immediately stops Amnify from being able to authenticate.
What Amnify never asks for on GCP
  • No write or modify roles, only the two read-only roles above.
  • No access to data-plane contents (Cloud Storage objects, database rows, Secret Manager values).
  • No broader access than the roles you grant the service account you created — a credential you own and can rotate or revoke at any time.