When creating an Octopus AWS Account (https://octopus.com/docs/infrastructure/deployment-targets/aws) you currently need to enter an AWS Access Key and Secret Key. This means the corresponding AWS Access Key needs to be periodically rotated, creating some management overhead and potential security vulnerabilities. Rather than an AWS Access Key and Secret Key, if we were able to enter an AWS IAM Role that is assumed whenever that Octopus AWS Account is used, then we would no longer need to manage AWS Access Keys.

In the background, Octopus Deploy would need to set it up so that the AWS IAM Role is assumed and temporary credentials (https://docs.aws.amazon.com/IAM/latest/UserGuide/idcredentialstemp_use-resources.html) are created whenever the corresponding Octopus AWS Account is used by a deploy process.

As for the credentials that are used to assume the AWS IAM Role, I would expect that the AWS service role for EC2 instances running the Octopus Deploy server / workers is used by default to assume the AWS IAM Role. And if Octopus is not running on EC2 instances, maybe as part of the creation of the Octopus AWS Account, when specifying the AWS IAM Role to assume, you could specify another Octopus AWS Account to use to assume that role. That way you could maintain a single AWS IAM User and Access Key, and then that user would be used to assume the AWS IAM Roles.

As an example, you could setup the Octopus Deploy server / workers EC2 role (or an IAM user) policy as follows:
Name: octopus-deploy-server
https://gist.github.com/burck1/5469acbff31b71fa69ef8d91c4426e50

Then when creating the AWS IAM Role that will be assumed as part of the deployment you would:
1. Setup the Trust Relationship as:
Name: octopus-deploy-my-project-deployer
https://gist.github.com/burck1/5469acbff31b71fa69ef8d91c4426e50
2. Setup the AWS IAM Role policy to have access to whatever AWS resources needed.

Note: This feature would also allow cross-account access as AWS IAM Roles can be assumed within other accounts.

At the moment (at least to my knowledge) the order in which prompted variables are shown is dependent on the variable name (ordered alphabetically).

It would be really cool if there was a possibility to give prompted variables an explicit order so that we can control in which order they appear in a simpler manner. For example it would be cool if one could just set a "priority" value for a prompted variable. This "priority" could be an integer and the prompts could then be ordered by this priority in descending order.

Unfortunately giving them names to achieve the correct order is problematic since we have some variables that are only prompted in some scopes and therefore it wouldn't really make sense to change their name because another scope needs them to appear in a certain order.

Sometimes when deploying, the user receives this message:

"For consistency, this deployment will use a snapshot of the variables and deployment process that was taken when the release was created, which does not include the latest changes that have been made to the project. A changed process can only be incorporated by creating a new release (this one may be renamed if desired). Variables can be updated via the release page, clicking Show to show the variables from the snapshot, and clicking the Update variables button."

It would be great to be able to tell the user exactly what changed, so they can make a judgement on whether or not to update variables or create a new release.

Ensuring certificates for the OD server are up to date are a little annoying. It would be awesome if the OD server could support renewing it's own hosting certificate with Let's Encrypt.

I've had a stab at creating custom steps to do this. The main issue is domain validation (DV). DNS validation often requires manual intervention and OD server controls http (see discussion at https://community.letsencrypt.org/t/domain-validation/26512 ).

The only way I see this really progressing forward is if OD server supports Let's Encrypt in the server as a maintanence task as it would be able to respond to http DV requests. It could then get the new certificate issued after successful http DV and update its https binding to use the new certificate.

I would also like to have the same thumbprint configured in the registry of the server for RDP access. An option to support this as part of the certificate renewal would be great.