Handling Passwords in Visual Studio / TFS Releases & Builds

by

Team Foundation Server (TFS) and Visual Studio Team Services (VSTS) have these really handy features that let you define DevOps release pipelines for your applications.  To get to it, go to the web portal for your Team Project and click the Releases tab.

Whether you use Releases (aka. “Release Management”) in TFS/VSTS or whether you use some other tool, one of the trickiest parts is handling usernames, passwords, and database connection strings.  Each environment that you deploy to probably has different server names and different passwords.  Typically, lots of people have the passwords for the development environment but for the production servers, there are probably just a very limited number of people who have that information.

So how do deal with this?  How do you make it so that not everyone can see the values?

Use Configuration Variables

The answer is that you should define configuration variables in your TFS/VSTS release definition.  These values can be stored at the Release level or at the Environment level.  To specify a configuration variable for the Release, click on the configuration tab and then add the variables.  (BTW, we’ll handle the encrypted stuff in a moment.)

Once you’ve defined the variables, you can then use these values in the steps (aka. “activities”) in your release.  You reference them using the $(variable-name) format as shown in the following image.

“But everyone can still see the password!”

Ok.  So you’ve got the values being used as configuration variables. But you still have the problem of the password being visible in cleartext.  This is an easy fix but it’s a little tough to see.  The answer is actually hidden in plain sight.  (BTW, thanks to my friend and fellow MVP, Angela Dugan @OakParkGirl for pointing this out.)

Go back to the Configuration tab where you defined the configuration variables for the release.

Hidden to the right of the value is a little lock icon.  Click that lock button and save your release definition.  Voila! that value is now encrypted.  

That’s it.  You’re done.

By the way, this same trick works on TFS Build Variables, too.

-Ben

 

— Looking to going good at DevOps & Scrum?  Need help getting your TFS/VSTS Releases working?  Trying to figure out how to achieve build-test-deploy enlightenment?  We can help.  Drop us a line at info@benday.com.  

 


10 Responses to "Handling Passwords in Visual Studio / TFS Releases & Builds"
  1. Thanks for the screenshot and the red arrow! I’ve been mad for weeks that the lock icon was only available at the Environment level and not the release level. But due to the poor UI the text boxes are SO WIDE on my large monitor I’d never noticed the lock icon at Release level, since its nearly at the bezel of my large monitor. Your screenshot looks like its from the Environment popup, where the lock icon is much more noticeable!

  2. I’ve been trying for days to get the Windows machine File Copy to accept an encrypted variable for the admin password. Each attempt results in failure. I’ve tried clear text within the variable with no luck. The only way I’ve gotten the release to complete successfully is by typing the password in clear text directly into the password field. We are using TFS 2015 R3 with build agents that are running Agent.Version 1.95.3. We use this same setup on the build definitions and those work without issue. I have to make this encrypted somehow in order to move forward. Are there other options? known bug perhaps?

    • The password contains upper and lower case letters and a number. No special characters in the password. The strange thing to me is that I am working on creating release definitions where currently everything (including the deploy) is happening in the build definition and this same step (windows machine file copy) is using the same variables and has the password variable locked/encrypted. It works when done through build, but when in releases it fails. Going into the step and removing the variable and just typing the admin password allows the release to deploy successfully. I first thought there could be something wrong with the encryption on the release side, but even when not locked/encrypted using a variable for the admin password ($(adminPassword)) causes the release to fail. I’m hoping there’s something I am missing, but so far I’m not seeing it.

  3. Great post! Question though: How do you stop anyone with permissions to edit a build/release definition from simply adding a PowerShell task and writing the sensitive content to a file or other output somewhere so they can see it? $(admin-password) | showMe.txt

    • There’s not much you can do about that from the perspective of VSTS/TFS. That’s a tough problem to solve no matter what platform you’re on because at some point you have to have a decrypted password. If that’s a huge concern for you, a possible answer is to put the password and/or connection string into an environment variable on the deployment target machine or to store it in the azure settings. In those cases, the build agent wouldn’t have access to that password at all. Of course, at that point, the problem simply moves — what’s to stop a rogue developer from writing a method that reads the config and dumps it to default.htm or something.

      Bottom line: if you don’t / can’t trust your people, you’re probably screwed.

      -Ben

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.