Deploy on GCP
This grants continuous.engineering access to your GCP project. You run one script, once. It binds our engineers' identities (riding their existing continuous.engineering SSO session, no new account to create) to the roles their work requires.
Run this in the project you want to grant access to:
gcloud auth login
curl -fsSL https://grant-access.continuous.engineering/gcp-deploy.sh -o gcp-deploy.sh
chmod +x gcp-deploy.sh
./gcp-deploy.sh --project <your-project-id> --admin-alert-email security@your-company.comThat's it: no project ID to share back with us; the script grants access directly. Sign in as a project owner or IAM admin first (gcloud auth login).
How it works
continuous.engineering engineers never get a native Google account in your project. Instead, our engineers' existing SSO identity is federated in through Workforce Identity Federation, GCP's mechanism for trusting an external identity provider directly, the same way your own workforce might federate through Okta or Entra ID. There's nothing to provision per engineer, and nothing left behind to clean up.
GCP has no equivalent of AWS's "assume a specific role for this session": every role bound to an identity is active for every session that identity opens. To still get real, audited separation between read-only work and admin work, the script binds three separate tiers (read / operate / admin) to three distinct federated identities, so which tier an engineer can reach is enforced by how they authenticated, not by convention. See the full role reference (or the GCP-specific breakdown) for why this differs from AWS and Azure.
What gets created
| Tier | Roles included | What it's for |
|---|---|---|
| read | CE-ReadOnly, CE-Security, CE-Billing | Read-only access, security audit, billing visibility |
| operate | CE-SRE, CE-DevOps, CE-Data | Day-to-day operational and infrastructure work (default) |
| admin | CE-Admin | Full project ownership, used only when the work requires it |
Also created: a custom CE-DenyProd deny policy (attach it to block access to anything tagged env-prod=true, even for the admin tier), OS Login enabled for IAM-based SSH with no persistent keys, and an alert channel for admin-tier activity.
See the full role reference (or the GCP-specific breakdown) for what each role can and cannot do.
Revoking access
./gcp-deploy.sh --project <your-project-id> --removeThis removes every binding the script created; best-effort, safe to run even if some bindings never existed.
Questions: devops@continuous.engineering