Roles Reference
This page is the detailed reference for every role the deploy script binds in your project. If you're deploying for the first time, start there; come back here for the specifics on what each role can and cannot do.
Two guardrails apply to every role below, and they're not repeated in each section:
- Tier-scoped, not session-scoped. GCP has no native "assume this specific role for this session" the way AWS does: every role bound to an identity is simultaneously active for every session that identity opens. To still get real, audited separation, our engineers authenticate through one of three distinct federated identities (read / operate / admin), and only the tier they authenticated through is reachable at all. See the Role Reference for why this differs from AWS and Azure.
- MFA, enforced at the source. continuous.engineering engineers authenticate through our own identity provider, which requires MFA at login for every engineer, every session. We don't re-check MFA again at your side: federated sessions don't reliably carry an MFA-present signal through to a downstream binding check, so a second condition on your side would be a check that can never usefully pass or fail. See the Security Model for the full explanation.
None of these roles can be reached by anyone outside continuous.engineering. Trust is scoped to our own federated identity pool, not to any individual engineer's Google account; there are no native Google accounts involved at all.
CE-ReadOnly
Read-only across all GCP services.
| Tier | read |
| GCP role | roles/viewer |
What this means in practice: an engineer with this role can look at anything in your project (resource configuration, metrics, logs, object listings and contents), but cannot change, create, or delete a single thing.
Used for: initial assessments, audits, architecture reviews, monitoring.
CE-Security
Read access to security-relevant services.
| Tier | read |
| GCP roles | roles/iam.securityReviewer, roles/logging.viewer |
What this means in practice: a superset of CE-ReadOnly focused on the audit trail and IAM policy visibility itself: who can do what, and what's already happened, without touching a resource.
Used for: security assessments, compliance audits, incident investigation.
CE-SRE
Read everything, restart/scale compute, remote shell via IAP.
| Tier | operate |
| GCP roles | roles/iap.tunnelResourceAccessor, roles/compute.osLogin |
| Additional | A narrow custom role for instance start/stop/reset |
What this means in practice: this role adds a narrow, explicit allow-list on top of read-only (start/stop/reset for compute instances), plus remote shell access via Identity-Aware Proxy (IAP) TCP forwarding, GCP's direct analog to AWS's Systems Manager Session Manager: no open ports, no SSH keys to manage, access brokered entirely through IAM.
Used for: incident response, operational support, performance troubleshooting.
CE-DevOps
Infrastructure build/modify access, deliberately narrower than AWS's equivalent role.
| Tier | operate |
| GCP role | A custom role (GCP has no predefined "editor minus IAM") |
| Custom role covers | Create/delete compute instances and disks |
What this means in practice: GCP's roles/editor is broader than what this role grants: its IAM/org-write exposure can't be closed off as cleanly as AWS's PowerUserAccess can with an explicit deny statement, so rather than grant roles/editor wholesale, this role ships as an intentionally narrower custom role scoped to compute build/teardown. If your engagement needs broader infrastructure scope on GCP, raise it with your engagement manager; it's a deliberate, conservative default, not a platform limit.
Used for: infrastructure builds, deployments, migrations (compute-focused).
CE-Data
Read access to BigQuery, Cloud Storage, and Cloud SQL.
| Tier | operate |
| GCP roles | roles/bigquery.dataViewer, roles/storage.objectViewer, roles/cloudsql.viewer |
What this means in practice: metadata and query access to your data layer: BigQuery datasets, Cloud Storage object listings/contents, Cloud SQL instance metadata.
A real gap worth knowing about: unlike AWS CE-Data, remote shell access here is not scoped to database=true-tagged instances only. CE-Data shares the same operate tier as CE-SRE, so an engineer with this role can shell into any instance in the project via IAP, not just database-tagged ones. Tag-scoped IAP access would need a per-instance IAM condition we haven't built yet. If this distinction matters for your compliance posture, tell your engagement manager before granting CE-Data on GCP.
Used for: data engineering, database administration, analytics work.
CE-Admin
Full project ownership.
| Tier | admin |
| GCP role | roles/owner |
What this means in practice: true roles/owner, full parity with AWS AdministratorAccess. Because tier separation on GCP happens at the identity level, not the session level, reaching this role requires authenticating through the dedicated admin-tier identity in the first place; it's not something an engineer can casually escalate into mid-session.
CE-Billing
Read-only billing and cost visibility.
| Tier | read |
| GCP role | roles/billing.viewer |
What this means in practice: billing visibility is a Billing Account-level role on GCP, not a project-level one: it's bound against your project's linked billing account specifically. Projects with no linked billing account simply can't grant this role; that's a normal state, not an error.
Used for: cost optimization engagements, spend review, budget/forecast work.
CE-Support
Not yet standardized for GCP the way CE-Support is for AWS: Google Cloud Customer Care role bindings vary by the support tier you've purchased, so this needs case-by-case confirmation with your engagement manager rather than a fixed default.
CE-DenyProd
Attach a deny policy to block access to anything tagged env-prod=true, applies across all three tiers, including admin.
Worth knowing: GCP deny policies work differently than AWS's. There's no universal deny-all wildcard; coverage has to be scoped per resource type (e.g. compute.googleapis.com/instances.*), and not every resource type accepts even that. Coverage ships with compute instances/disks confirmed working; if you need other resource types covered, ask your engagement manager to confirm and extend it before relying on it for a specific compliance requirement.
Still have questions?
Most edge cases are already covered in the FAQ; worth a search before you ask. For anything specific to your deployment, email devops@continuous.engineering.
Full deployment instructions are on the Deploy on GCP page.