Although some workflows can be performed without direct access to cloud resources, the power of automations that you build in OpenOps depends on the permissions that you assign. That said, you control which level of access to provide, as needed by the workflows that you build. One strategy is to start with providing OpenOps read-only permissions, and when you’re ready to automate update operations, provide more permissions.

Access to cloud resources in OpenOps is defined using “connections”: sets of resource credentials. OpenOps provides a separate tab to list and create connections:

Each workflow can use one or more connections, including multiple connections per resource. For example, you can have one connection for read-only AWS access and a different connection for updates.

You can set up connections in two ways:

  1. Upfront by going to the Connections tab and clicking New Connection. This opens a pop-up that lets you first select a connection type:
  2. While editing the workflow, in action properties, by opening the Connection dropdown and clicking Create Connection:

​
AWS connections

A connection to AWS requires specifying your access key ID, secret access key, and the default region:

You can create an IAM user in the AWS Management Console. When you do, you’ll get an access key ID and a secret access key to enter in the AWS connection configuration form. The specific set of permissions you assign to the user depends on what you want to do in the workflows that will use the AWS connection. For example, if you want your workflow to turn off EC2 instances, assign the ec2:StopInstances permission as shown in this guide.

If your AWS account doesn’t already have a default region, you can set it in the AWS Management Console separately.

If you have multiple AWS accounts and want one of them to define all the permissions that may be needed for workflows defined by OpenOps templates, consider installing the OpenOpsApp AWS Role Stack. Even if you don’t, you can download the stack and use it as a reference when configuring permissions for your workflows.

Connections to AWS Athena, AWS CloudFormation, and AWS Compute Optimizer are configured in the same way as AWS connections.

​
Connecting to multiple AWS accounts

OpenOps supports two approaches for working with multiple AWS accounts.

If you prefer to work with each account separately, you can create an AWS connection for each account. In this case, each connection should include that account’s access key ID, secret access key, and default region. You can then assign different connections to different workflow actions.

If you want to access multiple accounts together (for example, create a workflow that finds EC2 instances in multiple accounts), you can connect to the accounts from a single OpenOps connection. One account would have to have an assume-role trust with the other accounts. It is common to use the “payer” account in an organization for that purpose. To configure the connection in OpenOps:

  1. In the AWS connection UI, enter the access key ID, secret access key, and default region for a user in the central account. This user must have permission to assume roles in the other accounts.
  2. In the Roles section, click Add Item.
  3. For each additional AWS account you want to connect to, specify:
    • Assume role ARN: the Amazon resource name (ARN) of the IAM role to assume in this account (e.g., arn:aws:iam::123456789012:role/OpenOpsExecutionRole).
    • Assume role external ID: a shared secret defined in the IAM role’s trust policy. Leave this field blank if the role does not require an external ID.
    • Account alias: a convenience label used to identify this account in your workflows (e.g., dev, prod, billing).

You can add multiple entries in the Roles section to manage many accounts. When configuring a workflow, you’ll be able to choose which account to use with each action.

​
Azure connections

A connection to Azure requires specifying your application (client) ID, client secret, and directory (tenant) ID:

If you don’t already have these credentials, you can acquire them by creating an Azure service principal. There are two ways to do this: with the Azure CLI or the Azure Portal.

​
Creating an Azure service principal using the Azure CLI

Run the following Azure CLI command to create an Azure application and a service principal with the “Contributor” role at the subscription level:

az ad sp create-for-rbac --name "SomeAppName"

If you’d rather assign a different role to the service principal, specify the role using the --role flag instead. For example, this command assigns the “Reader” role to the service principal:

az ad sp create-for-rbac --name "SomeAppName" --role "Reader"

Whichever role you choose, the command returns JSON output similar to the following:

{
  "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "displayName": "<SomeAppName>",
  "password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Copy the values from the output into the respective fields in OpenOps connection properties:

  • appId to Application (client) ID
  • password to Client Secret
  • tenant to Directory (tenant) ID

​
Creating an Azure service principal using the Azure Portal

  1. From the Azure Portal home screen, go to App registrations and click New registration to create a new application:
  2. In the Overview section of the new application, you should now see the client ID and tenant ID. Copy these values into OpenOps.
  3. Go to the Certificates & Secrets submenu and create a new secret. Copy the secret to OpenOps now, as it will only be shown once.
  4. Go to the Subscriptions page and select a subscription for your new application’s service principal.
  5. Under the selected subscription, click Access control (IAM) on the left-side menu bar. In the view that opens, click Add, then select Add role assignment:
  6. In the Role step, select the role that you want your Azure connection to have. For a safe testing experience, use “Reader” or another read-only role. If you want to enable OpenOps to make changes to your Azure assets, choose “Contributor” or a more privileged role.
  7. In the Members step, click Select members and specify the name of your application. If your application does not appear in the dropdown immediately, search for it by name.
  8. Click Review + assign.

Your service principal is now ready to be used with your Azure connection in OpenOps.

​
Google Cloud connections

A connection to Google Cloud Platform (GCP) requires creating a GCP service account with permissions to use GCP services that you want OpenOps to interact with.

Once you have created a service account and exported a JSON service account key file, paste the contents of the file into the Key file content field, save the connection, and you’re good to go.