Secure way to provide credentials for services, scheduled tasks, and application pools?

Legacy Uncategorised
1

I’m new to both Octopus Deploy and Powershell scripts, but have managed to setup Octopus to deploy my services and tasks and start them using the local system account. However, I need to be able to set these up to run under domain accounts. I think I see how to do it with the powershell scripts but is there a secure way to get the credentials to the script? I don’t want to have all my service account passwords visible as clear text variables in Octopus deploy. Does Octopus deploy provide a user prompt to supply the credentials at the time of install? What are the best practices to achieve a secure deployment when a specific username and password are needed? Thanks!

2

Hi James,

You can use variables in the Octopus UI to store the credentials, and use the Octopus permissions system to lock down the variables so that only a select few people can see them. However the credentials will still be stored as plain text in the Octopus database, so it’s not the most secure option.

Another option would be to have the Tentacle service run under the context of a Windows user (a local admin), and to then find a way to give that Windows user access to some kind of external credential store via Windows authentication. A simple way would be to put the crendentials into a file on a file share, and then lock it down so that only the Tentacle windows user can read that file. Since the Tentacle agent will run the PowerShell scripts under the context of the user that the service is running under, you can use that.

Octopus doesn’t provide any way to prompt users for passwords during a deployment.

We do have a feature planned to allow some variable to be marked as ‘secret’ - these would be stored in the Octopus database as encrypted values, and only be visible to specific users.

Hope that helps,

Paul

3

Thanks for the quick response. I like the idea of the encrypted database values and hope to see it in a future release. When/if that feature is implemented, would the variable be temporarily stored in plain text on the destination machine during the deployment process?

4

Hi James,

It will be decrypted on the Octopus server, sent to the Tentacle via a secure WCF connection, and available in memory (possibly just as a secure string) to PowerShell. It won’t get written to disk anywhere, but it will be available for use as a variable in your PowerShell script (e.g., $MyPassword).

Paul

5

I think that would work for us! Any rough idea when this might be implemented? Weeks, months, years?

6

I’d say within the next month - it’s a relatively easy feature and I’m already making some changes in that area, so it won’t be too far away.

Paul

7

This is very important to my customers as well and will likely be the reason for rejecting Octopus if we can’t store passwords securely. Is there any progress on this feature?

8

Hi Robert,

You can prevent team members from viewing or editing variables using permissions (see this page).

We don’t, however, encrypt the values in the database. This is because the key needed for encryption would need to be externally managed (so that in a disaster, an Octopus database backup can be restored to a new server and the values can still be read), and we don’t have a good, secure way to manage that key yet.

Paul

9

Hi Paul

I take your point about a secure, central credential storage mechanism, but I think that is out of reach for most organisations for now.

I think securing the variables at rest is a key point to enable adoption in organisations with a low risk appetite. I’ve added outlined that in this UserVoice suggestion.

Sean

10

The ability to either supply secure passwords during the deployment process or have these variables stored securely is also important to our company. Is this in the works?

Thanks,
Allen

11

Hi, sorry for bumping an old thread, but has this feature been implemented? I can’t find it anywhere in Octopus.

Thanks

12

Hi,

We have plans to add a “prompt for passwords” options either when a deployment is queued, or during the deployment, where they’ll be stored and encrypted using DPAPI. This is something we’ll be adding in the Octopus 2.0 timeframe.

Paul

13

is this in the version 2.0.2.808 of octopus 2.0?

14

Hi Thom,

In Octopus 2.0 you can store variables and mark them as “sensitive”. For sensitive variables:

  • we never allow you to read the value back via the REST API or UI
  • we store them encrypted in the Octopus database using AES128
  • we do our best to mask them from any logs that we produce

Prompting for values at deployment time is something we plan to do a little later after 2.0 is release (we actually have a lot of the back end to support it, we just need some UI changes). But sensitive variables should be enough.

Paul