Hi I have a few questions and suggestions regarding how sensitive information is stored in variable templates.
I appreciate how values stored in sensitive/password boxes are not displayed when viewing tenant variables. However there are times when I need to access them and we are using Octopus as the central repository of them. In this case I will generally take a look at the outputted web.config to grab the password. It would be good if I could view this from within the Tenant itself somehow. Perhaps with an additional click to deobfuscate it
Further to this we also have an application that calls the Octopus API, it would be handy if it were also able to access these sensitive variables.
My other question relates to the possibility of using Octopus to generate random passwords for tenants based upon a particular length and complexity rules. Presently when creating a new tenant I use a separate app to do this and paste it into the field. It is further compounded in that we are now considering adding in a new tenant variable template for an additional key. In order to populate it we will have to navigate to each tenant, generate a password and enter it. I appreciate that we could probably script something ourselves to call your API but was wondering if this something that Octopus may be able to provide at some point.
Looking at this, it would break the level of security this feature provides. I use this feature as a secure storage and it has a onetime view when create.
Now, if you REALLY wanted to get these values out from the server, send me a direct message and I’ll explain how I did it.
But, it shouldn’t be easy to view these variables. That is what enable octopus to have a solid level of preventing users from finding out these pieces of data.
I agree that this may defeat the purpose of the sensitive variables in the first place and don’t have a big issue with this as I can work around it by setting up a simple deployment step that performs the transform and outputs them somewhere where I can access them.
On the other hand as there clearly are workarounds to this anyway I don’t see why it isn’t supported in the UI and API. Perhaps if there was a particular access level required and a separate API call required to obtain them.
I am interested to hear what Octopus have to say about whether Octopus being able to generate random keys is on the roadmap or if I am on my own in thinking this may be a useful feature.
Hi @mbotting
at the moment we have no plans to provide a random key generator built-in. I can certainly see its value, but since in the past we have assumed that users would be coming with ready-made passwords to put in to Octopus it hasn’t been prioritized as a must-have. Clearly that’s not always the case so perhaps it may be a feature that other users would find useful. My suggestion would be to add your idea to our uservoice site so that we can gauge how popular the feature is and can prioritize it accordingly.
As for your other point regarding to accessing sensitive variables, that is a bigger question. As noted by @asantaferra this would open up further avenues for potential security leaks that at the time did not feel like they would be worth the benefits (again for the same reason noted above it is assumed that there is a sensitive password store outside of Octopus). Since many people are starting to use Octopus as the primary store for these variables it might make sense to change this approach in future. Again we have a uservoice ticket tracking this feature request and it would be great to get your thoughts alongside it.
Let me know if you want any further clarification on my response
or have any other questions.