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.

Currently, the only way to set up AWS authentication for an ECR external feed, AWS deployment target, community library task, etc, is with an IAM user secret such as API access keypair. Our product secrutiy team has exlicitly forbidden use of secrets such as keypairs like this and requires everything to use IAM role authentication via role assumption.

It would be lovely to replace the access key and secret key inputs with a single input for an IAM role name to assume into in order to get the needed credentials. The authentication and login could then execute on workers with the proper node instance roles that allow for the needed role assumption.

All our workers in AWS are set up with proper roles that allow assumption into, e.g. ECR access role that can log in to ECR docker registry and browse the images. If executing from workers theres no need to supply credentials beyond the already-configured worker node IAM role.

Imagine you have a connection string variable and you want to update it. You would update the variable and redeploy, however if you made a mistake (edited the wrong variable or the new connection string was not live yet) then you cannot roll back. This is even more of a problem if the variable is sensitive as you can't copy it beforehand.

I would like to be able to version octopus variables, this would include:
- Who
- When
- When deployed
- The ability to roll back/forward.

At the moment we have to source control much of this type work, this obviously negates much of the valuable octopus functionality around environment handling/sensitive variables.

Add a PROCESS SNAPSHOT option for releases with an UPDATE PROCESSES button. This is the same thing that Octopus already has for variables. Just do it for Processes!

Nothing worse than having to make a small powershell script change then create a new release and run it back up the runway or having to temporarily manipulate the lifecycle to get it re-deployed to where you want it to go with the updated process.

I want to be able to go to the release. Hit update processes for that release to what I just changed on any process then be able to just re-deploy the same release to that environment with the steps i want to go.

Feel free to shoot it down boys. I'm all ears on why this is a bad idea.

When deploying application containers, there can be times when you want a password that no human needs to know and survives only for the lifetime of the container.

Our primary use case is generating secure keystores for certificates, etc. At container start-up, it will generate a new local keystore and we then have the ability to dynamically sign CSRs generated within the container via an external signing service.

We do not want to leave the keystore nor the certificate objects without any password, but also do not want to store the values anywhere external to the container.

Granted, we certainly can do things like set a short certificate lifetime, adopt policies such rapid container cycling, etc. in addition as a layered approach, but I see no reason to externally persist secrets that are of no use and add operational overhead to cycle manually.

We've been trying to ensure that any 'Step Templates' created in Octopus contain scripts/code (PowerShell) that exists within a package. That package is then referenced as part of the 'Step Template'.

The problem we have with this is that as soon as the package is pushed, it then gets used in any new releases. This means that we have no opportunity to test this in Octopus prior to new releases in pipelines using it.

It would be useful if within the 'Step Template' we could specify/fix the package version (or specify a range) used so that all other pipeline releases would use the specified version (rather than the latest) ... similar to some of the functionality that can be done in Channels..

https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5748518-rather-than-allways-taking-the-latest-version-of

... and it would be useful if, within a project pipeline, when a user was setting up use of the 'Step Template' that they had an option to override the package version defined by the step template (unless there was a setting in the 'Step Template' denying the ability to override it).

This would mean we can push the new 'Step Template' code/scripts/packages as much as we want, but we don't have to use them until the 'Step Template' is explicitly updated to use them.