Secure variables at rest
There are a number of suggestions for adding authorisation for access to variables through Octopus. Whilst this is absolutely needed, it does not go far enough. Especially for organisations with a low risk appetite.
Variables - which contain credentials and other sensitive information - need to be secured at rest. The fact that they are stored as plain text in a single DB and backups presents a very significant level of risk to an organisation. Should a backup or databse copy be accessed, all credentials are lost.
Further, no sensitive variables should be stored or logged on the tentacle. As far as I can see, they are only logged on the tentacle, but this may change for scheduled deployments.
Can I suggest the following?
** Securing Raven **
Add an option to secure the Raven database file using the RavenDB Encryption Bundle. This would allow administrators to mitigate the risk of the central DB being attacked.
** Securing the Tentacle **
Allow the marking of variables as secure so as to prevent storage by the tentacle. For scheduled deployments, store them encrypted (DPAPI perhaps) until the deployment has finished and then clean them up (even in the case of a failure - they can always be sent again if the deploy is rescheduled).
Sean Kearon
shared this idea
-
I posted some more details here: http://octopusdeploy.com/blog/encryption-in-2.0 - we're about to start work on this feature soon.
-
Sean Kearon
commented
That's fantastic - thanks for that, Paul. I'll look forwards to seeing 2.0!
-
For Octopus 2.0 we're taking inspiration from TeamCity. You'll be able to create a variable and mark it as being a "password". Passwords will be stored encrypted in the Octopus DB (though you may want to use the encryption bundle too). The raw value will be available in PowerShell scripts and can be added to XML config files, but we'll remove any occurrences of them from the log files so that they can't be accidentally logged to the UI.
-
Sean Kearon
commented
Hi Paul
Thanks, using the Raven encryption bundle would be a great option to have. I don't think the use of SecureString, that's not a vector I'm concerned about. The reasoning being that if the attacker is sophisticated enough to access the tentacle server and interrogate the memory, then it's game over in any case.
As for storing variables on the tentacle server - it looks like they are (or can be) logged during config file transformation. I see this in my logs:
2013-06-17 10:14:00 DEBUG [XML Configuration] Setting //*[local-name()='connectionStrings']/*[local-name()='add'][@name='Infrastructure.Live'] to 'data source=.\SQLEXPRESS;Initial Catalog=Pirform-Infrastructure;Persist Security Info=True;User ID=MyDB;Password=THISISVISIBLE'
Perhaps I'm not doing this right - is there a preferred way to add the passwords?
Thanks
Sean
-
Hi Sean,
I'll look into enabling the Raven encryption bundle.
Regarding the Tentacle, the variables are uploaded to the Tentacle over a secure connection. Once they reach the Tentacle, they are never stored anywhere. The only time they might be written to disk are:
1. When added to an XML configuration file using the inbuilt XML config/variable replacement feature
2. When a custom PowerShell script writes them to disk
3. They are temporarily written to disk prior to invoking the PowerShell scripts, but this file is always cleaned up after the script runs (successfully or not)In memory we could use SecureString to store them but we need to turn them into strings anyway to pass into PowerShell or to evaluate them, so they will be kept as strings floating about in memory anyway.
Paul
