Roles Reference
This page is the detailed reference for every IAM role the deploy stack creates in your account. 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:
- ExternalId. Every assumption must present
continuous.engineeras the ExternalId. This is what prevents a confused-deputy attack: without it, AWS rejects the call outright, regardless of who's asking. - MFA, enforced at the source. continuous.engineering engineers authenticate through our own IAM Identity Center (SSO), which requires MFA at login for every engineer, every session. We don't re-check MFA again at the point your role is assumed: AWS federated SSO sessions don't reliably carry an
aws:MultiFactorAuthPresentflag through to a downstreamAssumeRolecall, so a second MFA condition on your trust policy would be a check that can never actually pass, not an extra layer of security. If your compliance program requires you to see written confirmation of how our MFA is enforced, ask us; we're used to the question.
None of these roles can be assumed by anyone outside continuous.engineering. Trust is scoped to our stable IAM role (continuous-engineer-access in our own AWS account), not to any individual engineer's credentials.
CE-ReadOnly
Read-only across all AWS services. No write, delete, or modify of any kind.
| Managed policy | ReadOnlyAccess |
| Session | 4 hours |
What this means in practice: an engineer with this role can look at anything in your account (resource configuration, metrics, logs, S3 object listings and contents), but cannot change, create, or delete a single thing. It's the same blast radius as giving someone a screenshot of your console.
Used for: initial assessments, audits, architecture reviews, monitoring.
CE-Security
Read access to security-relevant services: CloudTrail, GuardDuty, Config, SecurityHub, IAM (read only).
| Managed policies | SecurityAudit, AmazonGuardDutyReadOnlyAccess, AWSCloudTrail_ReadOnlyAccess, AWSConfigUserAccess |
| Session | 4 hours |
What this means in practice: this is a superset of CE-ReadOnly focused on the audit trail itself: CloudTrail history, GuardDuty findings, Config compliance state, and IAM policy/role definitions (read-only; it cannot create or attach anything, even to itself). It's what we use to answer "what happened" and "who can do what" questions without touching a resource.
Used for: security assessments, compliance audits, incident investigation.
CE-SRE
Read everything, restart and scale services, access EC2 instances via SSM. Cannot create or delete infrastructure.
| Base | ReadOnlyAccess |
| Additional | Restart EC2/ECS/RDS/ASG, SSM shell on all instances, CloudWatch Logs |
| Session | 4 hours |
What this means in practice: this role adds a narrow, explicit allow-list on top of read-only: reboot/start/stop for EC2 and RDS, update/stop for ECS tasks, register/deregister load balancer targets, and adjust Auto Scaling capacity. It cannot launch new resources or delete anything. SSM shell access lets us get a terminal on an instance without opening port 22 or touching your security groups; see how SSM access works.
Used for: incident response, operational support, performance troubleshooting.
CE-DevOps
Broad infrastructure access. Can create and modify EC2, RDS, ECS, Lambda, VPCs, S3, and most services. Explicitly blocked from creating IAM users, roles, or policies, and from any Organizations actions.
| Base | PowerUserAccess |
| Denied | All IAM write, organizations:* |
| Session | 4 hours |
What this means in practice: PowerUserAccess is AWS's standard "build anything except identity" managed policy: it's broad on purpose, since this is the role we use for actual infrastructure work (standing up environments, running migrations, deploying services). The explicit deny on IAM write and Organizations actions is layered on top and cannot be overridden by PowerUserAccess: this role can never create a user, attach a policy, mint an access key, or touch account-level Organizations settings, no matter what else it's allowed to do. If you need us to be able to manage IAM directly, that's a conversation to have explicitly; it's not something this role grants by accident.
Used for: infrastructure builds, deployments, migrations.
CE-Data
Read access to RDS, S3, Athena, and Glue. SSM shell restricted to instances tagged database=true.
| Managed policies | AmazonRDSReadOnlyAccess, AmazonS3ReadOnlyAccess, AmazonAthenaFullAccess, AWSGlueConsoleReadOnlyAccess |
| SSM access | Instances tagged database=true only |
| Session | 4 hours |
What this means in practice: metadata and query access to your data layer (table structure, query history, S3 object listings/contents, Glue catalog), plus the ability to run Athena queries. SSM shell access is deliberately narrower here than CE-SRE: it only works on instances you've explicitly tagged database=true, so an engineer with this role cannot shell into an arbitrary web server just because they have data access. See scoping database instance access for the exact tag.
Used for: data engineering, database administration, analytics work.
CE-Admin
Full administrative access. Shortest session. Tightest MFA window. Your security team is emailed on every single assumption.
| Managed policy | AdministratorAccess |
| Session | 2 hours |
| Alert | Email to AdminAlertEmail on every assumption |
What this means in practice: this is the one role with no ceiling: full AdministratorAccess, including IAM write, that every other role explicitly denies. Because of that, it carries the shortest session window of any role (2 hours vs. 4) and triggers an immediate, no-exceptions email to your security team's AdminAlertEmail the moment it's assumed, not on a delay, not batched: every time. CE engineers escalate to CE-Admin only when the work genuinely requires IAM or account-level changes that no other role permits. Day-to-day work uses the least-privileged role appropriate for the task, and if you ever see a CE-Admin alert you weren't expecting, that's exactly the signal it's designed to give you: treat it as worth a quick check, and email us if anything looks off.
CE-Billing
Read-only billing and cost visibility. No access to anything outside billing/cost data.
| Managed policy | AWSBillingReadOnlyAccess |
| Additional | Cost Explorer API read (ce:Get*, ce:Describe*) |
| Session | 4 hours |
What this means in practice: ReadOnlyAccess (the policy every other read-capable role is built on) does not include billing or Cost Explorer; AWS gates those separately, and no single managed policy covers full Cost Explorer access, hence the small inline addition on top of AWSBillingReadOnlyAccess. This role exists specifically for FinOps and cost-optimization work (right-sizing recommendations, spend analysis, reserved instance/savings plan review) without granting visibility into anything else in your account.
Used for: cost optimization engagements, spend review, budget/forecast work.
CE-Support
Open and manage AWS Support cases on your behalf. No access to anything outside the Support Center.
| Managed policy | AWSSupportAccess |
| Session | 4 hours |
What this means in practice: MSPs routinely need to file support cases with AWS on a client's behalf (a stuck service limit increase, a suspected platform issue, an urgent P1 escalation), and that's a distinct permission (support:*) not covered by any other role, including CE-Admin. This role grants exactly that and nothing else.
Used for: filing/managing AWS Support cases, service limit increase requests, escalations.
CE-DenyProd (Managed Policy)
Not a role. A managed policy you attach to any CE role to block access to production resources.
Any resource tagged env-prod=true becomes inaccessible. The deny overrides all allow statements including those from AdministratorAccess.
What this means in practice: IAM evaluates explicit denies before any allow, with no exceptions: so once this policy is attached to a role, that role cannot touch a resource tagged env-prod=true even if the role is CE-Admin with full AdministratorAccess. This is the mechanism to use if you want us to have broad access to staging/dev but a hard technical wall around production, rather than relying on us to just not touch it.
Attach it to any role:
aws iam attach-role-policy \
--role-name CE-SRE \
--policy-arn <CEDenyProdPolicyArn from stack outputs>Still have questions?
Most edge cases are already covered in the FAQ; worth a search before you ask. For anything specific to your deployment (a permission you expected but don't see, a role that doesn't fit your compliance model, an assumption that's failing), email devops@continuous.engineering. We'd rather clarify up front than have you modify a role's trust policy or permissions on your own and end up in a state we can't support.
Full deployment instructions are on the Deploy on AWS page, and the complete picture (how the trust model works, what gets logged, how to revoke access) is on the grant-access home page.