cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Johnson <>
Subject Re: hidden configuration items revisited
Date Mon, 09 May 2016 13:53:17 GMT
Kishan Kavala <> 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


> ~kishan
> -----Original Message-----
> From: Nathan Johnson []
> Sent: 08 May 2016 22:01
> To:
> 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, , which  
> defaults to false.  This must be set to true in order for showhidden to  
> be allowed.  If showhidden=true is passed and  
>, an InvalidParameterValueException is  
> thrown.
> So the web UI would still hide hidden configuration items regardless of  
> the state of 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 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 out of my hat.  Is there a more  
> appropriate name that I should use?
> ==========
> 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.

View raw message