This January release of Octopus Deploy is primarily a security release driven by Octopus Cloud and will also benefit each of our customers running Octopus Deploy on-premises. We highly recommend upgrading.

You'll also notice our new versioning strategy: what would normally have been Octopus 4.2 is actually 2018.1. Read more about why we changed.

Octopus Cloud

One of our big drivers for this year is to bring our hosted Octopus offering to market, called Octopus Cloud. We are kicking off a closed Alpha program in the next few days - thank you to everyone who registered!

We've changed our versioning strategy

Read more about why we changed which also dives into our continuing evolution as a software product company.

Security enhancements

In preparation for Octopus Cloud we've performed penetration testing and a security audit. No major issues were found but uncovered a few smaller issues we wanted to fix. You may have seen several security fixes in recent patches. This feature release rolls up all of those patches, along with some extra enhancements you can use to make your Octopus Server more secure than ever.

New built-in roles and permissions

Octopus ships with several built-in teams and user roles, one of which is the Octopus Administrators team with the System Administrator role granting the rights to do anything and everything in your Octopus installation.

In Octopus 2018.1 we have effectively split the Octopus Administrators team and its System Administrator user role into two parts:

We've kept the existing Octopus Administrators team and System Administrator role which behave exactly the same as today

We've added a new Octopus Managers team and System Manager role which can do everything, except certain system-level functions reserved for system administrators

Actively preventing escalation of privileges (CVE-2018-5706)

The built-in user roles are sufficient for most common scenarios. In larger scale installations of Octopus people tend to tailor these user roles, or create their own user roles from scratch. The permissions system in Octopus is very powerful, but with great power comes additional complexity... and great responsibility. In earlier versions of Octopus, if you configured these roles incorrectly you might have accidentally granted a team the ability to escalate their own privileges.

Octopus 2018.1 has an additional layer of security which actively prevents any user from escalating their own or another user's privileges beyond the scope of their current scope of privileges.

Step package requirement

By default, Octopus performs package acquisition immediately before the first step in a deployment that requires packages. Steps can now be configured to run before or after package acquisition. The step condition Run this step has been replaced by Package requirement:

Previous:

New:

The new Package requirement allows a more explicit configuration of when a step should run with respect to package acquisition. There are three options to choose from:

Let Octopus Decide (default): Packages may be acquired before or after this step runs - Octopus will determine the best time

After package acquisition: Packages will be acquired before this step runs

Before package acquisition: Packages will be acquired after this step runs

This option is hidden when it does not make sense, for example, when a script step is configured to run after a package step (packages must be acquired by this point).

These options provide more flexibility when configuring complex parallel deployment processes to ensure that packages are acquired at the desired time. You can now configure a parallel block of steps that generate packages and use the option Before package acquisition to ensure that the packages can be consumed by subsequent package steps.

Breaking Changes

We've made two behavioral changes to Octopus which may impact certain customers.