Access Levels and Permissions

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.

​

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.