Role Reference
The same set of roles across every cloud: what each one is for, how long a session lasts, and whether your security team gets alerted when it's used. Deploy instructions live under AWS, GCP, and Azure; the Security Model page covers how trust and revocation work; Compliance maps all of this directly to SOC 2, ISO 27001, HIPAA, and PCI DSS for your auditors.
Roles
| Role | What it's for | Session | Alert on assume |
|---|---|---|---|
CE-ReadOnly | Read-only, all services | 4h | No |
CE-Security | Read-only + security findings, audit log, IAM read | 4h | No |
CE-SRE | Read-all + restart/scale + remote shell + logs | 4h | No |
CE-DevOps | All of CE-SRE + create/modify infra. Excludes IAM/org writes | 4h | No |
CE-Data | Read data (DB/storage/analytics) + remote shell on database=true-tagged instances only | 4h | No |
CE-Admin | Full admin, including IAM | 2h (shortest) | Yes, every time |
CE-Billing | Read-only billing/cost visibility, for FinOps work | 4h | No |
CE-Support | Open/manage cloud provider support cases on the client's behalf | 4h | No |
CE-Billing and CE-Support exist because MSP work needs more than generic read/write/admin tiers: cost visibility and support-case access are both gated separately from general access on every cloud, so neither was covered by the original roles.
A deeper, per-permission breakdown for AWS is on the AWS Roles Reference page.
CE-DenyProd
Not a role: an attachable policy. Blocks all access to anything tagged env-prod=true, overriding every other allow, including CE-Admin.
| Cloud | Available today |
|---|---|
| AWS | Yes: native IAM Deny policy |
| GCP | Yes: IAM Deny Policies, same override semantics (tag-conditioned) |
| Azure | Not yet: talk to your engagement manager about scoping access to specific resource groups instead if you need production carved out |
How trust works, per cloud
| Cloud | Mechanism |
|---|---|
| AWS | Our engineers assume a role in your account (STS AssumeRole), scoped to our own stable identity plus a shared secret (ExternalId) that prevents anyone else from using that trust. |
| GCP | Our engineers' existing SSO identity is federated directly into your project (Workforce Identity Federation); no native accounts created. |
| Azure | Our engineers are invited into your tenant as guests and assigned roles directly (Microsoft Entra B2B + native Azure RBAC). Every engineer authenticates with exactly one Azure credential: a dedicated account in our own Entra tenant, protected by MFA the same way our AWS and GCP access is. |
MFA is enforced once, at our own identity provider, not something re-verified at your side. This isn't a gap: federated sessions don't reliably carry a "recently completed MFA" signal through to the receiving cloud on any of the three, so a second check at your side would be one that can never usefully pass or fail. What you can rely on instead is that MFA is a hard, technical requirement for every one of our engineers, every session, before any access exists at all. See the Security Model for the full breakdown.
Questions: devops@continuous.engineering