FAQ
Can continuous.engineering access my account without me knowing?
No, on every cloud, though the mechanism differs slightly:
- AWS: the trust is two-way. Your CloudFormation stack trusts our identity provider, but we also have to add your account to our allow list on our side. Both must be in place. We do our side only when you tell us to.
- GCP: the script you run grants access directly by binding our federated identity to roles in your project: there's no separate CE-side step, so access exists exactly when and only when you've run it.
- Azure: the script invites our engineers as guests and assigns roles in one pass, same as GCP: access exists exactly when you've run it, and only for the engineers on the roster at that time.
What happens when the engagement ends?
| Cloud | What to run |
|---|---|
| AWS | Delete the CloudFormation stack. All CE roles are removed immediately. |
| GCP | ./gcp-deploy.sh --project <id> --remove |
| Azure | ./azure-deploy.sh --subscription <id> --remove |
We also remove your account from our side where that applies (AWS). Active AWS/GCP tokens expire within their remaining lifetime (max 4 hours). Nothing lingers.
Can I see what CE engineers are doing?
Depends on the cloud, and we'd rather be upfront about the difference than let you assume parity:
- AWS: yes, in full detail. The stack creates a dedicated CloudWatch log group and a 17-widget dashboard: every API call from every CE role, with engineer identity, action, resource, source IP, and timestamp. See the monitoring guide.
- GCP: every CE action appears in your project's Cloud Audit Logs under the federated identity's principal, queryable the same way any other activity is. We haven't built a dedicated dashboard for GCP yet.
- Azure: every CE action appears in your subscription's Activity Log under the individual guest's identity, and sign-in activity is visible in your tenant's Entra ID sign-in logs. No dedicated dashboard yet.
What if I only want to start with read-only access?
Tell us and we'll only use the read tier. On AWS/GCP you can also enforce this technically by deploying/binding only the read-tier roles; on Azure, ask us to run the roster with only CE-ReadOnly-tier engineers included. When broader access is appropriate, you tell us.
Can I restrict which engineers get which role?
Yes, but the control point differs:
- AWS/GCP: individual engineer access is managed on our side via SSO group membership (
ce-read/ce-operate/ce-admin). If you have specific requirements (e.g. only senior engineers onCE-Admin), raise this with your CE engagement manager; we enforce it on our end. - Azure: the roster we publish lists exactly which engineers are invited at which tier for every client running
azure-deploy.sh. Same request path: raise specific requirements with your engagement manager.
Does this require changes to my security groups or firewall?
No, on any cloud, though each uses a different no-open-ports mechanism:
- AWS: EC2 access goes through AWS Systems Manager Session Manager, over HTTPS port 443. Port 22 does not need to be open.
- GCP: instance access goes through Identity-Aware Proxy (IAP) TCP tunneling, also over HTTPS. No firewall rule needs to allow inbound SSH from CE.
- Azure: instance access goes through Azure Bastion with Entra ID authentication. No public IP or open port 22 required on the VM.
If your instances don't have the relevant agent installed (SSM agent / IAP-compatible OS Login / Bastion), CE can help set that up.
What is the ExternalId?
(AWS only.) The ExternalId (continuous.engineer) must be presented when our system assumes a role in your account. It prevents a confused deputy attack where a malicious actor tricks our identity provider into assuming your role on their behalf. Without the correct ExternalId, the call is rejected by AWS.
GCP and Azure don't have an ExternalId-equivalent field because their trust models prevent the same attack differently: GCP's tier binding is scoped to a specific federated provider, and Azure's guest-invitation model has no "assume a role" step to spoof in the first place.
Can I attach CE-DenyProd to CE-Admin?
On AWS and GCP, yes: even full admin access cannot touch resources tagged env-prod=true once CE-DenyProd is attached. The deny overrides AdministratorAccess (AWS) / roles/owner (GCP).
On Azure, this isn't available yet: RBAC Deny Assignments are the right mechanism but require additional tenant enrollment we haven't wired up. If you need production carved out on Azure today, talk to your engagement manager about scoping the invitation to specific resource groups instead of the whole subscription.
What if I have multiple accounts, projects, or subscriptions?
Run the relevant deploy step in each one and let us know. You can grant different roles/tiers in different accounts; there's no requirement that access be identical across your environment.
Is the deploy script auditable?
Yes. The CloudFormation template, gcp-deploy.sh, and azure-deploy.sh all live in a public GitHub repository. You can review exactly what any of them creates before running it. The deployed state in your own account/project/subscription also shows the current, live picture.
Do I need to sign anything before granting access?
Running any of these scripts is not itself a legal agreement. You should have a signed engagement agreement with continuous.engineering before granting access. If your environment handles PHI, a BAA is also required. Contact hello@continuous.engineering.