cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: hidden configuration items revisited
Date Mon, 09 May 2016 14:00:56 GMT
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 <njohnson@ena.com> wrote:

> Kishan Kavala <kishan.kavala@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:njohnson@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.
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message