Roles Reference
This page is the detailed reference for every role the deploy script assigns in your subscription. 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:
- Guest-scoped, not session-scoped. Access on Azure is a direct, named role assignment to an individually-invited guest, not a session-time choice: whichever tier an engineer is assigned is active for as long as the grant exists, not chosen fresh each time they connect. See the Role Reference for why this differs from AWS and GCP, and why keeping our engineer roster small and reviewed is the real control here.
- MFA, enforced at the source. Every continuous.engineering engineer has exactly one Azure credential: a dedicated account in our own Entra ID tenant, protected by MFA at every sign-in. Your tenant never evaluates MFA itself; a guest's sign-in redirects back to our tenant's own policy via standard home-realm discovery. See the Security Model for the full explanation.
None of these roles can be reached by anyone outside continuous.engineering. Access exists only for the individual engineers on our published roster, invited directly into your tenant; there's no shared principal or standing trust anchor to exploit.
CE-ReadOnly
Read-only across all Azure services.
| Tier | read |
| Azure role | Reader |
What this means in practice: an engineer with this role can look at anything in your subscription (resource configuration, metrics, logs), but cannot change, create, or delete a single thing.
Used for: initial assessments, audits, architecture reviews, monitoring.
CE-Security
Read access to security-relevant findings.
| Tier | read |
| Azure role | Security Reader |
What this means in practice: visibility into security findings and configuration without the ability to change anything.
Used for: security assessments, compliance audits, incident investigation.
CE-SRE
Read everything, restart/redeploy compute, remote shell via Bastion.
| Tier | operate |
| Azure roles | Reader + a custom CE-SRE-Restart role |
| Custom role covers | Start, restart, and redeploy virtual machines |
What this means in practice: this role adds a narrow, explicit allow-list on top of read-only (start/restart/redeploy for virtual machines), plus remote shell access via Azure Bastion with Entra ID authentication: no public IP, no open port 22, no SSH keys to manage.
Used for: incident response, operational support, performance troubleshooting.
CE-DevOps
Broad infrastructure build/modify access, excluding identity management.
| Tier | operate |
| Azure role | Contributor |
What this means in practice: Contributor is Azure's standard "build anything except identity" built-in role: broad on purpose, since this is the role used for actual infrastructure work. It already excludes Microsoft.Authorization/roleAssignments/write by default, so no extra exclusion is layered on top the way AWS/GCP need one bolted onto their broad build roles.
Used for: infrastructure builds, deployments, migrations.
CE-Data
Read access to blob storage.
| Tier | operate |
| Azure role | Storage Blob Data Reader |
| Remote shell | Bastion, scoped to database=true-tagged VMs, same restriction pattern as AWS CE-Data |
What this means in practice: read access to your data layer's storage contents, with remote shell deliberately narrower than CE-DevOps's: only reachable on instances you've explicitly tagged.
A gap worth knowing about: database-service-specific read roles (SQL/Cosmos DB/Postgres) aren't wired into the deploy script yet: the exact built-in role name needs to be confirmed against whichever database service you're actually running before it's added. If your engagement needs read access to a managed database service specifically, raise it with your engagement manager.
Used for: data engineering, database administration, analytics work.
CE-Admin
Full administrative access, including identity management.
| Tier | admin |
| Azure role | Owner |
What this means in practice: true Owner, full parity with AWS AdministratorAccess and GCP roles/owner. This wasn't always the plan: an earlier design based on Azure Lighthouse (cross-tenant delegation) turned out to structurally cap admin access below Owner, so we moved to the guest-invitation model described here specifically to deliver real parity.
CE-Billing
Read-only billing and cost visibility.
| Tier | read |
| Azure role | Cost Management Reader |
Used for: cost optimization engagements, spend review, budget/forecast work.
CE-Support
Not yet researched in depth for Azure; excluded from the deploy script until confirmed. If your engagement needs CE to open Azure support cases on your behalf, raise it with your engagement manager.
CE-DenyProd
Not yet available on Azure. RBAC Deny Assignments are the right mechanism, but they require additional tenant enrollment we haven't wired up; Microsoft's own guidance also frames Deny Assignments as a less battle-tested control than the equivalent on AWS/GCP. If you need production carved out entirely, talk to your engagement manager about scoping the invitation to specific resource groups instead of the whole subscription.
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 Azure page.