Feature
Cloud Access & Trust
How OrchesTerra connects to your cloud accounts: scoped roles with a per-tenant External ID, separate read-only and deploy roles, encrypted credentials scoped to your workspace, and a sandboxed runner for plans and applies.
Before you connect a production account to any platform, you should know exactly what it can do there. This page describes the access OrchesTerra asks for and the controls around it.
A role, not a key
On AWS, OrchesTerra assumes an IAM role in your account. You do not hand over long-lived access keys.
- One-click setup. A CloudFormation quick-create link opens in your AWS console with the template filled in. You review it and create the stack; nothing is created without you.
- Per-tenant External ID. The role's trust policy requires an External ID unique to your workspace, which protects against the confused-deputy problem: another OrchesTerra customer cannot get us to act on your account.
- Separate read-only and deploy roles. The template creates a read-only role for scans, discovery, drift and cost, and an optional deploy role that is used only for plans and changes. You can connect read-only first and add deploy access later, or never.
Locked-down sessions
Every time OrchesTerra assumes a role, the session is named for its purpose and tagged with the workspace, user and job, so CloudTrail shows exactly who and what each call was for.
The template can also lock the roles to a list of source IP addresses. Calls from any other address are denied, so a leaked session is useless elsewhere.
Credentials, encrypted and scoped
Whatever a connection needs (role details for AWS, service principals or service accounts for Azure, Google Cloud and OCI) is encrypted at rest and scoped to your workspace. One workspace cannot read another's credentials.
A separate, sandboxed runner
Terraform and OpenTofu plans and applies don't run inside the web application. They run on a separate runner, each job in a throwaway container under a gVisor sandbox, which limits what a malicious provider or module could reach if it tried.
Nothing applies without approval
Access is only part of the control. Every apply waits for the approval chain you configure, and every action lands in the audit log.
Related: Security & posture, SSO + SCIM.
FAQ
Can we start read-only?
Yes. Connect with the read-only role to get discovery, drift and cost, and add the deploy role when you are ready to provision through OrchesTerra.
Can we remove access?
Delete the CloudFormation stack (or the role) and OrchesTerra loses access immediately.