AikidoSec/gcp-onboarding-terraform-module: how to onboard a cloud scanner without a shared secret

This Terraform module encodes least privilege, API enablement, and keyless trust into one repeatable GCP handoff.

7 min read • View on GitHub • More from AikidoSec

A wide editorial scene shows a cloud control room laid out like a workbench. A Terraform file, a permission checklist, and a service account sit on one side, while a security scanner waits beyond a glass partition on the other. The image explains that the real product is not scanning itself, but the trust boundary that lets scanning begin safely. — Onboarding is the product when the thing you are onboarding is allowed into your cloud.

Key Takeaways

The module matters because it turns cloud access into a declared trust relationship instead of a manual setup ritual.
Terraform makes the onboarding legible, reviewable, and versioned, which is the real security gain.
Its biggest win is not automation for its own sake, but removing long-lived shared secrets from the path.
A small onboarding repo can still define the trust boundary for an entire security product.

The scanner does not start with scanning

The interesting part of this repo is not the scan. It is the moment before the scan, when a security tool asks for access to a cloud account and the team has to decide how much trust to grant. That decision is usually where setup gets messy: console clicks, copied keys, hidden permissions, and a future round of drift.

This module sets up the necessary IAM roles and Workload Identity Federation to allow Aikido to scan your GCP organization or project.

Aikido Documentation, Official Documentation · AikidoSec/gcp-onboarding-terraform-module README

That sentence is the whole story in miniature. The module is not a convenience wrapper around setup, it is the mechanism that defines what Aikido can see, how it gets in, and how that access stays narrow enough to audit.

Why Terraform is the right handshake

Aikido is speaking to a team that already trusts infrastructure as code. If your cloud is managed through pull requests, then security onboarding belongs there too. Terraform turns a sensitive permission grant into something the team can review, diff, approve, and repeat across projects without recreating the setup from scratch.

That is the origin context here. The module exists because the fastest way to make a cloud scanner usable is not a wizard, it is a handoff that fits the operating model of the people who own the cloud.

What the module actually provisions

At a practical level, the module wires together the pieces that make a scanner legitimate inside GCP. Think service accounts, IAM bindings, and Workload Identity Federation, plus the supporting GCP services the scan depends on. The point is to let Aikido authenticate without turning identity into a static secret that can linger long after the onboarding PR is merged.

The module replaces a shared secret with a constrained identity exchange.

That flow is the technical center of gravity. The module is really a compact trust protocol: Terraform declares the resources, GCP enforces the permissions, and Aikido uses the resulting identity path to read the cloud without owning a long-lived key.

The real differentiator is keyless access

A lot of onboarding flows still collapse into one ugly sentence: here is a key, please keep it safe. This module points somewhere better. It makes the access relationship explicit, short-lived, and reviewable. That matters because the blast radius of a cloud security tool should be narrow by design, not narrow by habit.

A close-up shows a set of permission tiles being assembled into a custom role. Some tiles snap cleanly into place, while others are left on the table, cut away from the final shape. An unused key rests off to the side, visibly disconnected. The image explains least privilege as a design choice, not a slogan. — The security gain comes from narrowing identity before the scanner ever starts reading.

That is the real difference between onboarding a vendor and handing over a password. One creates a permission contract. The other creates a liability.

How it compares to manual setup and generic IAM

The comparison is not really about features. It is about operational shape. Manual console setup is easy to start and hard to trust later. A generic IAM module gives you primitives, but you still have to design the trust model yourself. Aikido's module packages that decision for one specific use case.

Approach	Setup effort	Auditability	Drift risk	Blast radius	Secretless?
Aikido Terraform module	Moderate	High	Low	Narrow	Yes
Manual GCP Console onboarding	Low at first	Low	High	Often broad	No
Generic IAM module	Moderate	Medium	Medium	Depends on design	Usually not
Vendor script or wizard	Low	Medium	Medium	Variable	Sometimes

That makes the repo more specific, and more useful, than a general IAM toolkit. It is opinionated in the way a good security product should be. The module does not just connect a SaaS vendor to GCP. It preserves the shape of the trust decision so the customer can keep owning it.

What this says about modern security tooling

This repo is a small example of a larger shift. Security products are moving from vague integrations toward declared trust. The best onboarding experience is not the one that hides the permission model. It is the one that makes the permission model readable enough to sign off on.

That is why a tiny Terraform module can matter so much. It is not just setup code. It is the contract that decides how a scanner enters the room, what it can touch, and how easily a team can prove that the access stayed narrow.