Cloud Account¶

Onboarding your Cloud Accounts¶

To configure your own account, you can grant us a security role through different mechanisms to provision infrastructure on your behalf. If you wish to host on our account, you can skip this step.

Here is how it looks like:

• For AWS, we have a 1-click integration to create your Cloudformation stack. For step-by-step instructions, here is a link to the video
• For GCP, we have a 1-click integration using Cloud Shell to create the security role. For step-by-step instructions, here is a link to the video
• For Azure, we have a 1-click integration using Azure Cloud Shell to create the security role. For step-by-step instructions, here is a link to the video
• For OCI, we provide a shell script that configures the required identity resources in your tenancy. OCI is currently supported for Custom Tenancy deployments only (Plan Specification).

Hosted vs BYOC responsibility model¶

The onboarding flow is the same entry point, but the account owner differs by deployment model:

• Hosted deployment: you connect one of your own cloud accounts so Omnistrate can bootstrap deployment cells there for hosted instances.
• BYOC deployment: each customer connects the cloud account where their workloads will run. Omnistrate then bootstraps deployment cells in that customer account and reuses them for later deployments in the same account and region.

In both cases, Omnistrate provides the onboarding artifacts and automates the bootstrap sequence. The cloud account owner runs the cloud-provider-specific onboarding flow and approves the required IAM and identity setup.

Required permissions for onboarding¶

Permissions required to execute account onboarding vary depending on the cloud provider.

AWS¶

User executing the CloudFormation stack needs to have AdministratorAccess on the AWS account.

GCP¶

User executing the Cloud Shell script needs to have roles/owner on the GCP project.

Azure¶

User executing the Cloud Shell script should use the following baseline permissions:

• Azure subscription: Owner or User Access Administrator
• Microsoft Entra ID: Application Administrator
• Microsoft Entra ID: Privileged Role Administrator

Do not assume Azure subscription Owner alone is sufficient. The onboarding flow also needs Microsoft Entra permissions to create or manage the application identity and assign roles.

OCI¶

User executing the onboarding shell script needs to have administrator access to the OCI tenancy. The script creates identity resources (users, groups, policies, and compartments) in the specified tenancy and domain, so the user must be able to manage identity domains and create OCI IAM policies.

You will need the following identifiers when onboarding:

• Tenancy OCID: The OCID of your OCI tenancy (e.g., ocid1.tenancy.oc1..aaa...)
• Domain OCID: The OCID of the identity domain to use (e.g., ocid1.domain.oc1..aaa...)

Common Issues During Account Onboarding¶

AWS Load Balancer Controller Policy Already Exists¶

Problem: AWS accounts sometimes have the AWS Load Balancer Controller Policy already installed, which can result in CloudFormation stack errors due to duplicate policy creation attempts.

Solution: When onboarding your AWS account, if you encounter errors related to the AWS Load Balancer Controller Policy already existing, you need to configure the CloudFormation parameter to skip the policy installation.

During the AWS account onboarding process:

1. Set the CloudFormation parameter for AWS Load Balancer Controller Policy creation to false
2. This will skip the installation of the policy and avoid the duplicate resource error
3. The existing policy in your account will be used instead

Cloud Account already used in different Environment¶

Problem: You used a cloud account to one Omnistrate Organization and later attempted to add it to a different Omnistrate Organization, which resulted an error message.

Solution: This is expected behavior. The same cloud account can be used across different environments (dev, staging, prod) within the same organization, but cannot be used across different organizations. This is a security feature to prevent account conflicts and ensure proper isolation between organizations.

If you need to use the same cloud account across different organizations, you'll need to:

1. Remove the account from the first organization
2. Wait for the removal to complete
3. Add it to the second organization

Retrying a Partial or Failed Onboarding¶

Problem: The onboarding flow partially succeeded, or bootstrap resources were later modified or deleted manually, and a retry now fails in ways that are hard to interpret.

Solution: Treat the retry as a fresh onboarding unless you are certain the original bootstrap artifacts are still intact.

Recommended guidance:

1. Use the current onboarding flow generated for the target cloud account and environment.
2. Do not mix artifacts from another cloud provider, account, project, subscription, or an older onboarding run.
3. If bootstrap identities or trust resources were deleted manually, remove the account configuration in Omnistrate and onboard again cleanly.
4. For GCP specifically, if the project was deleted and recreated, or if workload identity resources were removed out of band, prefer a clean re-onboarding instead of attempting to reuse stale state.

Offboarding¶

When you no longer need a cloud account connected to Omnistrate, you can offboard it to remove all Omnistrate-managed resources and revoke access. The offboarding process is automated and handles cleanup of infrastructure artifacts that were created during onboarding.

Before you offboard¶

Before initiating the offboarding process:

1. Delete all deployment instances running in the cloud account. Active instances must be removed before offboarding can proceed.
2. Wait for the instance delete workflows to finish before you remove onboarding artifacts from the cloud account. Omnistrate may still need those identities and trust relationships to clean up deployment cells, networking, and other platform-managed resources.

Offboarding steps¶

Follow these steps to offboard a cloud account:

1. Navigate to System Settings > Cloud Accounts in the Omnistrate Console.
2. Locate the cloud account you want to offboard.
3. Click Delete on the account configuration.
4. Wait for Omnistrate to finish platform cleanup. During this phase the account may remain in Deleting while Omnistrate removes deployment cells, networking, and other platform-managed resources.
5. Do not delete the onboarding artifacts from your cloud account while the account is still Deleting. Omnistrate may still need the bootstrap identities and trust configuration to complete cleanup.
6. Once Omnistrate marks the account as Ready_to_offboard, remove the onboarding artifacts from your cloud provider:

AWS¶

Delete the CloudFormation stack that was created during onboarding:

1. Open the AWS CloudFormation Console.
2. Locate the Omnistrate onboarding stack.
3. Select the stack and choose Delete.
4. Wait for the stack deletion to complete.

GCP¶

Run the offboarding script using Cloud Shell:

1. Open Google Cloud Shell.
2. Run the offboarding script provided during the onboarding process to remove the service account and IAM bindings.

Azure¶

Run the offboarding script using Azure Cloud Shell:

1. Open Azure Cloud Shell.
2. Run the offboarding script provided during the onboarding process to remove the service principal, role assignments, and related resources.

OCI¶

Run the offboarding script provided during onboarding:

1. Open the OCI Cloud Shell or a terminal with OCI CLI configured.
2. Run the offboarding script to remove the identity resources (users, groups, policies, and compartments) created during onboarding.

If onboarding artifacts were deleted too early¶

If the CloudFormation stack, GCP onboarding resources, Azure service principal, or OCI identity resources were deleted before the account reached Ready_to_offboard, cleanup can get stuck.

Recommended recovery:

1. Restore or recreate the onboarding artifact if possible.
2. Retry the Omnistrate offboarding flow.
3. If the target account, project, or subscription was materially changed out of band, prefer a clean re-onboarding instead of trying to reuse stale bootstrap state.

What offboarding cleans up¶

When you delete the account configuration, Omnistrate automatically removes all deployment cells and their underlying infrastructure (control plane, networking, and system components).

For any questions about the offboarding process, reach out to [email protected].