Skip to main content
The Google Cloud integration connects your Google Cloud and Google Workspace environment to Keldyn’s continuous-evidence engine. Once connected, Keldyn reads your access, identity, authentication, and privileged-access posture on a schedule and turns it into live evidence for the related controls — so you don’t have to re-check and re-attach that evidence by hand.
Integrations and automated evidence are typically managed by workspace admins. See Evidence & audits for how automated evidence fits alongside manual evidence.

​
What it’s used for

Keldyn uses the data it reads from Google to keep the evidence for your access-management controls current. Each nightly refresh updates the evidence and the freshness status shown on the integration’s Controls covered table. The integration contributes evidence to these ISO 27001 controls:
ControlTopicCoverage
A.8.3 — Information access restrictionWho can access whatFull
A.5.15 — Access controlRole/entitlement assignmentsFull
A.5.16 — Identity managementAccount roster and lifecycleFull
A.8.5 — Secure authenticationStrong-authentication posture and sign-in factorsFull
A.8.2 — Privileged access rightsPrivileged entitlements and grantsFull
A.8.18 — Use of privileged utility programsJust-in-time privileged accessFull
A.5.18 — Access rightsRemoving access (suspended/deleted accounts)Partial
A.5.3 — Segregation of dutiesPoint-in-time role snapshotPartial
Full coverage means the data is the artifact the control asks for. Partial coverage means the data usefully contributes but does not, on its own, replace everything the control requires (for example, A.5.18 also needs provisioning/deprovisioning records and access-certification results). Keldyn labels partial coverage in the auto-generated evidence so it isn’t mistaken for complete coverage.

​
Before you begin

1

Sign in with the right Google account

You connect with your own Google account using OAuth. Keldyn only ever reads what that signed-in account can already access — connecting does not grant Keldyn org-wide access.
2

Use a Google Workspace admin for full coverage

Reading the identity inventory, 2-Step Verification posture, and sign-in audit logs requires the signed-in user to be a Google Workspace admin. If you connect with a non-admin account, IAM and privileged-access evidence still works, but identity and authentication controls will show Access required.
3

Enable the required APIs

Make sure the Cloud Resource Manager, IAM, Privileged Access Manager, Admin SDK Directory, and Admin Reports APIs are enabled for the project you connect.

​
Set up the integration

1

Open Integrations

In the Keldyn web app, go to Integrations and select Google Cloud.
2

Connect

Select Connect and complete the Google sign-in and consent screen. Review the requested read-only scopes and approve them.
3

Run the first sync

After connecting, select Sync now to pull evidence immediately, or wait for the next scheduled refresh. The Controls covered and Evidence sources tables then show what was collected and how fresh it is.
From an integration’s detail page, Controls covered shows, per control, whether Google is actively feeding it and whether the control is satisfied. Evidence sources shows each data fetch, the controls it covers, and its freshness.

​
What data Keldyn collects and why

Keldyn requests read-only access and never writes to your Google environment. It collects only the data below, and only to build control evidence.
Data collectedWhat it containsWhy Keldyn collects itRefresh
IAM policy role bindingsWhich users, groups, and service accounts hold which roles, on which projects/resourcesShows who has access and what they can do — the core evidence for access-restriction and access-controlDaily
Identity lifecycle inventoryThe account roster with status (active, suspended, deleted) plus create/suspend/delete lifecycle events, including suspendedAt/deletedAt timestampsEvidences identity management, and shows access being removed for leaversDaily
2-Step Verification enforcementWhether strong authentication is enforced and how many identities are enrolledEvidences the authentication posture required for secure authenticationDaily
Sign-in audit logsWhich authentication factor was actually satisfied at log-onConfirms secure authentication is working in practice, not just configuredDaily
Privileged Access Manager entitlements and grantsPrivileged entitlements and just-in-time access grantsEvidences privileged access rights and use of privileged utilitiesDaily

​
Permissions and scopes

Keldyn requests these OAuth scopes. All are read-only.
ScopePurpose
openid, email, profileIdentify the signed-in Google user
cloud-platformProject discovery, IAM policy reads, and Privileged Access Manager reads
admin.directory.user.readonlyWorkspace identity inventory and 2-Step Verification posture (requires a Workspace admin)
admin.reports.audit.readonlySign-in audit logs and identity lifecycle audit events (requires a Workspace admin)
Google’s Privileged Access Manager only accepts the full cloud-platform scope, not a read-only variant. Keldyn still performs only read operations with it.

​
Troubleshooting “Access required”

A control shows Access required when your connected account is missing the matching permission, isn’t a Workspace admin, or the relevant API isn’t enabled. For example:
  • resourcemanager.projects.getIamPolicy is needed for IAM role bindings.
  • privilegedaccessmanager.entitlements.list is needed for privileged access.
  • Workspace-admin rights are needed for identity inventory and 2-Step Verification.
Reconnect with an account that has the required access, or enable the missing API, then run Sync now again.

​
Keeping evidence current

Keldyn refreshes Google evidence automatically each day. Evidence that hasn’t refreshed within its expected cadence is marked stale, and failed pulls are marked failed so you can spot gaps. You can also trigger an immediate refresh at any time with Sync now.

​
Next steps

Evidence & audits

Learn how automated integration evidence works alongside manual evidence and audits.