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.
