Re: hidden configuration items revisited

[Erik Weber]

Rajani is right, I didn't look at the value in db, just the category.

-- 
Erik

On Tue, May 10, 2016 at 8:30 AM, Rajani Karuturi  wrote:

> 'Hidden' and 'Secure' are both encrypted in db only difference being hidden
> values are not shown.
> you could just change the category in configuration table.
>
> ~Rajani
>
> On Mon, May 9, 2016 at 10:56 PM, Erik Weber  wrote:
>
> > listConfiguration returns unencrypted values for Secure items, but they
> > need to be stored encrypted in the db.
> >
> > You'd need to check If those values ever change, If they don't you may
> try
> > encrypting the value and change category to Secure
> >
> > Erik
> >
> > Den mandag 9. mai 2016 skrev Nathan Johnson  følgende:
> >
> > > Erik Weber > wrote:
> > >
> > > > 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.
> > >
> > > This is chicken and egg.  I need the unencrypted values so I can
> decrypt
> > > other payloads.  I need the keys plaintext, one way or another.
> > >
> >
>

Re: hidden configuration items revisited

[Rajani Karuturi]

'Hidden' and 'Secure' are both encrypted in db only difference being hidden
values are not shown.
you could just change the category in configuration table.

~Rajani

On Mon, May 9, 2016 at 10:56 PM, Erik Weber  wrote:

> listConfiguration returns unencrypted values for Secure items, but they
> need to be stored encrypted in the db.
>
> You'd need to check If those values ever change, If they don't you may try
> encrypting the value and change category to Secure
>
> Erik
>
> Den mandag 9. mai 2016 skrev Nathan Johnson  følgende:
>
> > Erik Weber > wrote:
> >
> > > 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.
> >
> > This is chicken and egg.  I need the unencrypted values so I can decrypt
> > other payloads.  I need the keys plaintext, one way or another.
> >
>

Re: hidden configuration items revisited

[Erik Weber]

listConfiguration returns unencrypted values for Secure items, but they
need to be stored encrypted in the db.

You'd need to check If those values ever change, If they don't you may try
encrypting the value and change category to Secure

Erik

Den mandag 9. mai 2016 skrev Nathan Johnson  følgende:

> Erik Weber > wrote:
>
> > 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.
>
> This is chicken and egg.  I need the unencrypted values so I can decrypt
> other payloads.  I need the keys plaintext, one way or another.
>

Re: hidden configuration items revisited

[Nathan Johnson]

Erik Weber  wrote:

> 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.

This is chicken and egg.  I need the unencrypted values so I can decrypt  
other payloads.  I need the keys plaintext, one way or another.

Re: hidden configuration items revisited

[Erik Weber]

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.
>
>
>

Re: hidden configuration items revisited

[Nathan Johnson]

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.

RE: hidden configuration items revisited

[Kishan Kavala]

Nathan,
  You can use "Secure" category instead of "Hidden". Config items with "Secure" 
category are encrypted and also included in listConfigurations API response. 

~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.

hidden configuration items revisited

[Nathan Johnson]

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?