I believe Kishan suggested that you could change those Hidden config items to Secure (an existing category), as Secure items are returned with the listConfiguration API.
I don't know if you can do an in-place switch, or if the value has to be encrypted first for it to work, but you should be able to test that in a test environment. -- Erik On Mon, May 9, 2016 at 3:53 PM, Nathan Johnson <njohn...@ena.com> wrote: > Kishan Kavala <kishan.kav...@accelerite.com> wrote: > > > Nathan, > > You can use "Secure" category instead of "Hidden". Config items with > "Secure" category are encrypted and also included in listConfigurations API > response. > > The data that I need (specifically security.encryption.iv and > security.encryption.key) are already marked “Hidden". These are the keys > that are used to encrypt the response that I need to decrypt in the > middleware. The configuration item I’m proposing to add is a boolean, so > that doesn’t make sense to be “Secure” either. Unless I’m > misunderstanding? > > Thanks for the reply > > Nathan > > > > > > ~kishan > > > > -----Original Message----- > > From: Nathan Johnson [mailto:njohn...@ena.com] > > Sent: 08 May 2016 22:01 > > To: dev@cloudstack.apache.org > > Subject: hidden configuration items revisited > > > > I would like to get some feedback for a proposed addition of a feature > > that would allow “Hidden” configuration items to be returned from the > > listConfigurations endpoint. > > > > 1) There will be a new optional parameter for listConfigurations called > > showhidden . Defaults to false. Existing behavior is preserved unless > > showhidden is set to true. > > > > 2) There is a now configuration item, com.cloud.allowshowhidden , which > > defaults to false. This must be set to true in order for showhidden to > > be allowed. If showhidden=true is passed and > > com.cloud.allowshowhidden=false, an InvalidParameterValueException is > > thrown. > > > > So the web UI would still hide hidden configuration items regardless of > > the state of com.cloud.allowshowhidden since it will not be passing > > showhidden=true. The main value of this would be from API > > implementations / middleware, which is what our front-end talks to > > instead of directly to cloudstack management server. > > > > Obviously there is an explicit reason hidden configuration items are not > > displayed via the API at present. The Hidden configuration items contain > > some very sensitive data, such as private keys etc. I would like to > > submit a pull request that would make sense to everyone and still be > > secure by default and not open up pandora’s box so to speak. I have this > > working in our lab, but I wanted to get a bit of feedback before > > submitting a PR. > > > > So several questions: > > > > 1) Would it make sense for com.cloud.allowshowhidden to be a “Hidden” > > configuration item? The up side of this is that you could not toggle > > this value from the API. Marking it hidden means that a rogue root admin > > api key holder could not grant themselves more access. The down side is > > that I’m not sure how to easily change this value outside of manually > > going into the database and changing it, and one should hope that root > > admin api key holders are well trusted. Currently I have this > > implemented as an “Advanced” configuration item. > > > > 2) I picked com.cloud.allowshowhidden out of my hat. Is there a more > > appropriate name that I should use? > > > > > > > > > > DISCLAIMER > > ========== > > This e-mail may contain privileged and confidential information which is > > the property of Accelerite, a Persistent Systems business. It is intended > > only for the use of the individual or entity to which it is addressed. If > > you are not the intended recipient, you are not authorized to read, > > retain, copy, print, distribute or use this message. If you have received > > this communication in error, please notify the sender and delete all > > copies of this message. Accelerite, a Persistent Systems business does > > not accept any liability for virus infected mails. > > >
