Introducing Spacelift Cloud Integrations

At Spacelift, we’re excited to announce our new Cloud Integrations section and our update to support account-level AWS integrations. Public Cloud integration is nothing new in Spacelift, but we wanted to simplify the implementation and organization. Cloud Integrations brings feature parity to AWS and Azure integrations across your Spacelift account.

We’ve created a new Cloud Integrations section in the Spacelift console. This section allows you to manage AWS and Azure integrations from a single location. Azure integrations were previously in the settings section and have been moved from there.

In addition, we’ve added the ability to attach more than one AWS integration to your stack:

A stack can have at most two AWS integrations attached, with only one read and one write integration (see “Read vs. Write Attachments” for more info). An integration can also be attached as both read and write for simple use-cases.

Finally, we’ve also altered the external ID format used when assuming roles. More details are available later in this post.

Don’t worry, your existing AWS integrations will continue to work, and the existing spacelift_aws_role resource can still be used. The only caveat to this is that you will only be able to add new integrations to stacks via the front end using the new Cloud Integrations approach.

Migrating from legacy integrations is easy, with slightly different steps depending on whether you manage your integrations via Terraform or the Spacelift UI. In the simplest case, you just need to create a new integration, delete your old integration, and attach a new one, but you may also need to adjust the Trust Relationships for your IAM roles depending on exactly how they are configured.

For more information on migrating, take a look at our documentation.

An integration can be attached to a stack as either read or write. This tells Spacelift which run phases to use each integration during. For simple use-cases, you can attach a single integration as both read and write, but if you want more control, you can create a read-only role and a write role, and attach both to your stack. An example use-case for this is to make sure that a proposed run doesn’t have write permissions to avoid infrastructure changes being made via a pull request.

Read attachments are used during the Initialize and Plan phases of runs. Write attachments are used during the Apply phase of a run, the Perform phase of a task, and the Destroy phase of a stack destructor.

When choosing to assume the role at Spacelift’s end rather than on your private workers, we automatically generate an External ID based on the stack the integration is attached to. Previously we used the following external ID format:

As part of the changes we’ve made, we’ve adjusted our external ID format to the following:

The change means that you can use the “read” or “write” suffix to ensure that a read phase of a run can only assume a read-only role.

We really hope that these changes will be useful and will provide extra flexibility for those users who need it while making simple use-cases easier through reusing integrations. To find out more about Cloud Integrations, review the documentation.