You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Robert Levas <rl...@cloudera.com.INVALID> on 2019/02/25 20:09:41 UTC
[DISCUSS] Environment variables should be usable when looking up passwords
Team...
I would like to open a discussion on adding a feature to Knox to allow the
Gateway get a password from the environment as well as the remote and local
credential stores. This is potentially needed by management consoles, like
Cloudera Manager, that can create keystores but pass the credentials for
them using environment variables.
See KIP-13 Environment variables should be usable when looking up passwords
<https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords>
for
more information.
The relevant JIRA is KNOX-1794
<https://issues.apache.org/jira/browse/KNOX-1794>.
Rob
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by larry mccay <lm...@apache.org>.
Thanks for bringing this up and adding a KIP for it, Rob!
I do get uneasy with the idea of this even though I do realize that it is
done by things like CM.
In order to get something into an environment variable, the secrets often
end up in script files or available in ps listings, logs, etc.
If we enable this, we will need to be very careful of where these sorts of
things can get exposed.
I will spend some more time with the KIP now.
On Mon, Feb 25, 2019 at 3:09 PM Robert Levas <rl...@cloudera.com.invalid>
wrote:
> Team...
>
> I would like to open a discussion on adding a feature to Knox to allow the
> Gateway get a password from the environment as well as the remote and local
> credential stores. This is potentially needed by management consoles, like
> Cloudera Manager, that can create keystores but pass the credentials for
> them using environment variables.
>
> See KIP-13 Environment variables should be usable when looking up passwords
> <
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> >
> for
> more information.
>
> The relevant JIRA is KNOX-1794
> <https://issues.apache.org/jira/browse/KNOX-1794>.
>
> Rob
>
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by Phil Zampino <pz...@apache.org>.
I know the discovery mechanism employs aliases for usernames also.
On Tue, Feb 26, 2019 at 9:03 AM Robert Levas <rl...@cloudera.com.invalid>
wrote:
> >
> > It is unclear to me whether you are proposing this for all uses of the
> > AliasService or just for the keystore and truststore passwords that are
> > configured at the gateway-site.xml level.
>
>
> Actually, I didn't make a distinction. I thought that the job of the
> AliasService was to provide a value stored under some name, where the
> name/value pair was stored either remotely or locally. In most cases this
> essentially seemed to be a "named" password. Maybe the AliasService serves
> a larger purpose, thus making my proposal a bit out of whack.
>
> In any case, my thought (which might be wrong) was that the AliasService
> served up *named passwords*. The name (alias) was looked up in a configured
> remote storage facility, first, and if not found, it looks in the local
> storage facility. Adding the ability to set named passwords in the
> environment would just be one more layer to this onion. So the
> AliasService would now look to the environment variables as well as the
> remote and local storage facilities. I am not sure what the priority would
> be, but my initial design was to have the AliasService look to the
> environment first and then to the remote and local storage facilities.
>
> Maybe this is too broad and abuses the usage of the AliasService. If that
> is the case, then maybe we limit this only to the TLS and signing keystores
> and keys. But the logic to get the passwords would need to be handled by
> the user of the keystore or key rather than internally by the
> AliasService.
>
> Rob
>
>
> On Mon, Feb 25, 2019 at 5:06 PM larry mccay <lm...@apache.org> wrote:
>
> > It is unclear to me whether you are proposing this for all uses of the
> > AliasService or just for the keystore and truststore passwords that are
> > configured at the gateway-site.xml level.
> > If you intend for this to work across the board:
> >
> > 1. I would have to understand why
> > 2. there would need to be further qualification of the env variable names
> > to incorporate topology names
> >
> > If it is only intended for passwords at the gateway-site.xml level then
> > this should be reflected in the KIP.
> >
> > Apologies if it already is stated and I have missed it.
> >
> >
> > On Mon, Feb 25, 2019 at 4:41 PM Kevin Risden <kr...@apache.org> wrote:
> >
> > > Another thought:
> > >
> > > A way to potentially look at this is to use the existing env.VARIABLE
> > > support and have the AliasService check if it is actually an alias.
> This
> > > pattern is used in the Pac4j stuff where the topology has a value like
> > > ${alias=...}. Without it being a ${alias=...}, the value is just used
> as
> > a
> > > password. This would allow either a regular password or an alias to be
> > > used. Backwards compatibility becomes really ugly here since you
> wouldn't
> > > know if existing values are passwords or aliases.
> > >
> > > So if some property has a value if "env.USER", when querying the
> Gateway
> > > > config for that value, "env.USER" will not be returned. Instead
> > something
> > > > like "rlevas" will be?
> > > >
> > >
> > > Yes. Works pretty well for env.VARIABLE and also sys.VARIABLE works for
> > > system properties. GatewayConfigImpl.init() has info about how those
> get
> > > set.
> > >
> > > Kevin Risden
> > >
> > >
> > > On Mon, Feb 25, 2019 at 4:34 PM Robert Levas
> <rlevas@cloudera.com.invalid
> > >
> > > wrote:
> > >
> > > > >
> > > > > I guess one of the questions that comes to mind is do we need to
> > > support
> > > > > the environment variable being updated while Knox is running?
> > > >
> > > >
> > > > I am not sure that this is possible. I wrote a little test program
> and
> > > was
> > > > not able to alter the environment variable according to the running
> > > > process's point of view.
> > > >
> > > > If environment variables will not be updated while Knox is running,
> > then
> > > > > why don't we push aliases provided by environment variables to the
> > > > > LocalAliasService.
> > > >
> > > >
> > > > So I guess we should be able to bootstrap the local alias service
> with
> > > the
> > > > relevant values, as long as we can identity them. This will alter
> my
> > > > initial workflow by not allowing the environment variables to
> override
> > > the
> > > > remote credential store. I am not set on either order, but I thought
> > that
> > > > typically the more dynamic the value, the higher priority it gets.
> For
> > > > example: Args -> Environment variables -> System properties ->
> Store
> > > data
> > > >
> > > > Finally, we need to be careful with "env." prefixes since Hadoop
> > > > > configuration already handles that case (which GatewayConfigImpl
> > > extends
> > > > > from). Meaning that env.ENVRIONMENT name properties are actually
> > > > available
> > > > > today.
> > > >
> > > >
> > > > Good point. I didn't realize this. So some other decoration can be
> > used.
> > > > So if some property has a value if "env.USER", when querying the
> > Gateway
> > > > config for that value, "env.USER" will not be returned. Instead
> > something
> > > > like "rlevas" will be?
> > > >
> > > > Rob
> > > >
> > > >
> > > >
> > > > On Mon, Feb 25, 2019 at 3:18 PM
> > > > Kevin Risden
> > > > <kr...@apache.org> wrote:
> > > >
> > > > > I guess one of the questions that comes to mind is do we need to
> > > support
> > > > > the environment variable being updated while Knox is running?
> > > > >
> > > > > I don't know if the environment can be changed from underneath a
> > > running
> > > > > process. One area that this is also interesting is with
> > > Kubernetes/Docker
> > > > > and how secrets can be managed.
> > > > >
> > > > > If environment variables will not be updated while Knox is running,
> > > then
> > > > > why don't we push aliases provided by environment variables to the
> > > > > LocalAliasService. This would avoid having to do special handling
> for
> > > > > environment variable lookups. Basically bootstrap the local alias
> > > service
> > > > > with the environment variable passwords.
> > > > >
> > > > > Finally, we need to be careful with "env." prefixes since Hadoop
> > > > > configuration already handles that case (which GatewayConfigImpl
> > > extends
> > > > > from). Meaning that env.ENVRIONMENT name properties are actually
> > > > available
> > > > > today.
> > > > >
> > > > > Kevin Risden
> > > > >
> > > > >
> > > > > On Mon, Feb 25, 2019 at 3:10 PM Robert Levas
> > > <rlevas@cloudera.com.invalid
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Team...
> > > > > >
> > > > > > I would like to open a discussion on adding a feature to Knox to
> > > allow
> > > > > the
> > > > > > Gateway get a password from the environment as well as the remote
> > and
> > > > > local
> > > > > > credential stores. This is potentially needed by management
> > > consoles,
> > > > > like
> > > > > > Cloudera Manager, that can create keystores but pass the
> > credentials
> > > > for
> > > > > > them using environment variables.
> > > > > >
> > > > > > See KIP-13 Environment variables should be usable when looking up
> > > > > passwords
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> > > > > > >
> > > > > > for
> > > > > > more information.
> > > > > >
> > > > > > The relevant JIRA is KNOX-1794
> > > > > > <https://issues.apache.org/jira/browse/KNOX-1794>.
> > > > > >
> > > > > > Rob
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by Robert Levas <rl...@cloudera.com.INVALID>.
>
> It is unclear to me whether you are proposing this for all uses of the
> AliasService or just for the keystore and truststore passwords that are
> configured at the gateway-site.xml level.
Actually, I didn't make a distinction. I thought that the job of the
AliasService was to provide a value stored under some name, where the
name/value pair was stored either remotely or locally. In most cases this
essentially seemed to be a "named" password. Maybe the AliasService serves
a larger purpose, thus making my proposal a bit out of whack.
In any case, my thought (which might be wrong) was that the AliasService
served up *named passwords*. The name (alias) was looked up in a configured
remote storage facility, first, and if not found, it looks in the local
storage facility. Adding the ability to set named passwords in the
environment would just be one more layer to this onion. So the
AliasService would now look to the environment variables as well as the
remote and local storage facilities. I am not sure what the priority would
be, but my initial design was to have the AliasService look to the
environment first and then to the remote and local storage facilities.
Maybe this is too broad and abuses the usage of the AliasService. If that
is the case, then maybe we limit this only to the TLS and signing keystores
and keys. But the logic to get the passwords would need to be handled by
the user of the keystore or key rather than internally by the
AliasService.
Rob
On Mon, Feb 25, 2019 at 5:06 PM larry mccay <lm...@apache.org> wrote:
> It is unclear to me whether you are proposing this for all uses of the
> AliasService or just for the keystore and truststore passwords that are
> configured at the gateway-site.xml level.
> If you intend for this to work across the board:
>
> 1. I would have to understand why
> 2. there would need to be further qualification of the env variable names
> to incorporate topology names
>
> If it is only intended for passwords at the gateway-site.xml level then
> this should be reflected in the KIP.
>
> Apologies if it already is stated and I have missed it.
>
>
> On Mon, Feb 25, 2019 at 4:41 PM Kevin Risden <kr...@apache.org> wrote:
>
> > Another thought:
> >
> > A way to potentially look at this is to use the existing env.VARIABLE
> > support and have the AliasService check if it is actually an alias. This
> > pattern is used in the Pac4j stuff where the topology has a value like
> > ${alias=...}. Without it being a ${alias=...}, the value is just used as
> a
> > password. This would allow either a regular password or an alias to be
> > used. Backwards compatibility becomes really ugly here since you wouldn't
> > know if existing values are passwords or aliases.
> >
> > So if some property has a value if "env.USER", when querying the Gateway
> > > config for that value, "env.USER" will not be returned. Instead
> something
> > > like "rlevas" will be?
> > >
> >
> > Yes. Works pretty well for env.VARIABLE and also sys.VARIABLE works for
> > system properties. GatewayConfigImpl.init() has info about how those get
> > set.
> >
> > Kevin Risden
> >
> >
> > On Mon, Feb 25, 2019 at 4:34 PM Robert Levas <rlevas@cloudera.com.invalid
> >
> > wrote:
> >
> > > >
> > > > I guess one of the questions that comes to mind is do we need to
> > support
> > > > the environment variable being updated while Knox is running?
> > >
> > >
> > > I am not sure that this is possible. I wrote a little test program and
> > was
> > > not able to alter the environment variable according to the running
> > > process's point of view.
> > >
> > > If environment variables will not be updated while Knox is running,
> then
> > > > why don't we push aliases provided by environment variables to the
> > > > LocalAliasService.
> > >
> > >
> > > So I guess we should be able to bootstrap the local alias service with
> > the
> > > relevant values, as long as we can identity them. This will alter my
> > > initial workflow by not allowing the environment variables to override
> > the
> > > remote credential store. I am not set on either order, but I thought
> that
> > > typically the more dynamic the value, the higher priority it gets. For
> > > example: Args -> Environment variables -> System properties -> Store
> > data
> > >
> > > Finally, we need to be careful with "env." prefixes since Hadoop
> > > > configuration already handles that case (which GatewayConfigImpl
> > extends
> > > > from). Meaning that env.ENVRIONMENT name properties are actually
> > > available
> > > > today.
> > >
> > >
> > > Good point. I didn't realize this. So some other decoration can be
> used.
> > > So if some property has a value if "env.USER", when querying the
> Gateway
> > > config for that value, "env.USER" will not be returned. Instead
> something
> > > like "rlevas" will be?
> > >
> > > Rob
> > >
> > >
> > >
> > > On Mon, Feb 25, 2019 at 3:18 PM
> > > Kevin Risden
> > > <kr...@apache.org> wrote:
> > >
> > > > I guess one of the questions that comes to mind is do we need to
> > support
> > > > the environment variable being updated while Knox is running?
> > > >
> > > > I don't know if the environment can be changed from underneath a
> > running
> > > > process. One area that this is also interesting is with
> > Kubernetes/Docker
> > > > and how secrets can be managed.
> > > >
> > > > If environment variables will not be updated while Knox is running,
> > then
> > > > why don't we push aliases provided by environment variables to the
> > > > LocalAliasService. This would avoid having to do special handling for
> > > > environment variable lookups. Basically bootstrap the local alias
> > service
> > > > with the environment variable passwords.
> > > >
> > > > Finally, we need to be careful with "env." prefixes since Hadoop
> > > > configuration already handles that case (which GatewayConfigImpl
> > extends
> > > > from). Meaning that env.ENVRIONMENT name properties are actually
> > > available
> > > > today.
> > > >
> > > > Kevin Risden
> > > >
> > > >
> > > > On Mon, Feb 25, 2019 at 3:10 PM Robert Levas
> > <rlevas@cloudera.com.invalid
> > > >
> > > > wrote:
> > > >
> > > > > Team...
> > > > >
> > > > > I would like to open a discussion on adding a feature to Knox to
> > allow
> > > > the
> > > > > Gateway get a password from the environment as well as the remote
> and
> > > > local
> > > > > credential stores. This is potentially needed by management
> > consoles,
> > > > like
> > > > > Cloudera Manager, that can create keystores but pass the
> credentials
> > > for
> > > > > them using environment variables.
> > > > >
> > > > > See KIP-13 Environment variables should be usable when looking up
> > > > passwords
> > > > > <
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> > > > > >
> > > > > for
> > > > > more information.
> > > > >
> > > > > The relevant JIRA is KNOX-1794
> > > > > <https://issues.apache.org/jira/browse/KNOX-1794>.
> > > > >
> > > > > Rob
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by larry mccay <lm...@apache.org>.
It is unclear to me whether you are proposing this for all uses of the
AliasService or just for the keystore and truststore passwords that are
configured at the gateway-site.xml level.
If you intend for this to work across the board:
1. I would have to understand why
2. there would need to be further qualification of the env variable names
to incorporate topology names
If it is only intended for passwords at the gateway-site.xml level then
this should be reflected in the KIP.
Apologies if it already is stated and I have missed it.
On Mon, Feb 25, 2019 at 4:41 PM Kevin Risden <kr...@apache.org> wrote:
> Another thought:
>
> A way to potentially look at this is to use the existing env.VARIABLE
> support and have the AliasService check if it is actually an alias. This
> pattern is used in the Pac4j stuff where the topology has a value like
> ${alias=...}. Without it being a ${alias=...}, the value is just used as a
> password. This would allow either a regular password or an alias to be
> used. Backwards compatibility becomes really ugly here since you wouldn't
> know if existing values are passwords or aliases.
>
> So if some property has a value if "env.USER", when querying the Gateway
> > config for that value, "env.USER" will not be returned. Instead something
> > like "rlevas" will be?
> >
>
> Yes. Works pretty well for env.VARIABLE and also sys.VARIABLE works for
> system properties. GatewayConfigImpl.init() has info about how those get
> set.
>
> Kevin Risden
>
>
> On Mon, Feb 25, 2019 at 4:34 PM Robert Levas <rl...@cloudera.com.invalid>
> wrote:
>
> > >
> > > I guess one of the questions that comes to mind is do we need to
> support
> > > the environment variable being updated while Knox is running?
> >
> >
> > I am not sure that this is possible. I wrote a little test program and
> was
> > not able to alter the environment variable according to the running
> > process's point of view.
> >
> > If environment variables will not be updated while Knox is running, then
> > > why don't we push aliases provided by environment variables to the
> > > LocalAliasService.
> >
> >
> > So I guess we should be able to bootstrap the local alias service with
> the
> > relevant values, as long as we can identity them. This will alter my
> > initial workflow by not allowing the environment variables to override
> the
> > remote credential store. I am not set on either order, but I thought that
> > typically the more dynamic the value, the higher priority it gets. For
> > example: Args -> Environment variables -> System properties -> Store
> data
> >
> > Finally, we need to be careful with "env." prefixes since Hadoop
> > > configuration already handles that case (which GatewayConfigImpl
> extends
> > > from). Meaning that env.ENVRIONMENT name properties are actually
> > available
> > > today.
> >
> >
> > Good point. I didn't realize this. So some other decoration can be used.
> > So if some property has a value if "env.USER", when querying the Gateway
> > config for that value, "env.USER" will not be returned. Instead something
> > like "rlevas" will be?
> >
> > Rob
> >
> >
> >
> > On Mon, Feb 25, 2019 at 3:18 PM
> > Kevin Risden
> > <kr...@apache.org> wrote:
> >
> > > I guess one of the questions that comes to mind is do we need to
> support
> > > the environment variable being updated while Knox is running?
> > >
> > > I don't know if the environment can be changed from underneath a
> running
> > > process. One area that this is also interesting is with
> Kubernetes/Docker
> > > and how secrets can be managed.
> > >
> > > If environment variables will not be updated while Knox is running,
> then
> > > why don't we push aliases provided by environment variables to the
> > > LocalAliasService. This would avoid having to do special handling for
> > > environment variable lookups. Basically bootstrap the local alias
> service
> > > with the environment variable passwords.
> > >
> > > Finally, we need to be careful with "env." prefixes since Hadoop
> > > configuration already handles that case (which GatewayConfigImpl
> extends
> > > from). Meaning that env.ENVRIONMENT name properties are actually
> > available
> > > today.
> > >
> > > Kevin Risden
> > >
> > >
> > > On Mon, Feb 25, 2019 at 3:10 PM Robert Levas
> <rlevas@cloudera.com.invalid
> > >
> > > wrote:
> > >
> > > > Team...
> > > >
> > > > I would like to open a discussion on adding a feature to Knox to
> allow
> > > the
> > > > Gateway get a password from the environment as well as the remote and
> > > local
> > > > credential stores. This is potentially needed by management
> consoles,
> > > like
> > > > Cloudera Manager, that can create keystores but pass the credentials
> > for
> > > > them using environment variables.
> > > >
> > > > See KIP-13 Environment variables should be usable when looking up
> > > passwords
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> > > > >
> > > > for
> > > > more information.
> > > >
> > > > The relevant JIRA is KNOX-1794
> > > > <https://issues.apache.org/jira/browse/KNOX-1794>.
> > > >
> > > > Rob
> > > >
> > >
> >
>
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by Kevin Risden <kr...@apache.org>.
Another thought:
A way to potentially look at this is to use the existing env.VARIABLE
support and have the AliasService check if it is actually an alias. This
pattern is used in the Pac4j stuff where the topology has a value like
${alias=...}. Without it being a ${alias=...}, the value is just used as a
password. This would allow either a regular password or an alias to be
used. Backwards compatibility becomes really ugly here since you wouldn't
know if existing values are passwords or aliases.
So if some property has a value if "env.USER", when querying the Gateway
> config for that value, "env.USER" will not be returned. Instead something
> like "rlevas" will be?
>
Yes. Works pretty well for env.VARIABLE and also sys.VARIABLE works for
system properties. GatewayConfigImpl.init() has info about how those get
set.
Kevin Risden
On Mon, Feb 25, 2019 at 4:34 PM Robert Levas <rl...@cloudera.com.invalid>
wrote:
> >
> > I guess one of the questions that comes to mind is do we need to support
> > the environment variable being updated while Knox is running?
>
>
> I am not sure that this is possible. I wrote a little test program and was
> not able to alter the environment variable according to the running
> process's point of view.
>
> If environment variables will not be updated while Knox is running, then
> > why don't we push aliases provided by environment variables to the
> > LocalAliasService.
>
>
> So I guess we should be able to bootstrap the local alias service with the
> relevant values, as long as we can identity them. This will alter my
> initial workflow by not allowing the environment variables to override the
> remote credential store. I am not set on either order, but I thought that
> typically the more dynamic the value, the higher priority it gets. For
> example: Args -> Environment variables -> System properties -> Store data
>
> Finally, we need to be careful with "env." prefixes since Hadoop
> > configuration already handles that case (which GatewayConfigImpl extends
> > from). Meaning that env.ENVRIONMENT name properties are actually
> available
> > today.
>
>
> Good point. I didn't realize this. So some other decoration can be used.
> So if some property has a value if "env.USER", when querying the Gateway
> config for that value, "env.USER" will not be returned. Instead something
> like "rlevas" will be?
>
> Rob
>
>
>
> On Mon, Feb 25, 2019 at 3:18 PM
> Kevin Risden
> <kr...@apache.org> wrote:
>
> > I guess one of the questions that comes to mind is do we need to support
> > the environment variable being updated while Knox is running?
> >
> > I don't know if the environment can be changed from underneath a running
> > process. One area that this is also interesting is with Kubernetes/Docker
> > and how secrets can be managed.
> >
> > If environment variables will not be updated while Knox is running, then
> > why don't we push aliases provided by environment variables to the
> > LocalAliasService. This would avoid having to do special handling for
> > environment variable lookups. Basically bootstrap the local alias service
> > with the environment variable passwords.
> >
> > Finally, we need to be careful with "env." prefixes since Hadoop
> > configuration already handles that case (which GatewayConfigImpl extends
> > from). Meaning that env.ENVRIONMENT name properties are actually
> available
> > today.
> >
> > Kevin Risden
> >
> >
> > On Mon, Feb 25, 2019 at 3:10 PM Robert Levas <rlevas@cloudera.com.invalid
> >
> > wrote:
> >
> > > Team...
> > >
> > > I would like to open a discussion on adding a feature to Knox to allow
> > the
> > > Gateway get a password from the environment as well as the remote and
> > local
> > > credential stores. This is potentially needed by management consoles,
> > like
> > > Cloudera Manager, that can create keystores but pass the credentials
> for
> > > them using environment variables.
> > >
> > > See KIP-13 Environment variables should be usable when looking up
> > passwords
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> > > >
> > > for
> > > more information.
> > >
> > > The relevant JIRA is KNOX-1794
> > > <https://issues.apache.org/jira/browse/KNOX-1794>.
> > >
> > > Rob
> > >
> >
>
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by Robert Levas <rl...@cloudera.com.INVALID>.
>
> I guess one of the questions that comes to mind is do we need to support
> the environment variable being updated while Knox is running?
I am not sure that this is possible. I wrote a little test program and was
not able to alter the environment variable according to the running
process's point of view.
If environment variables will not be updated while Knox is running, then
> why don't we push aliases provided by environment variables to the
> LocalAliasService.
So I guess we should be able to bootstrap the local alias service with the
relevant values, as long as we can identity them. This will alter my
initial workflow by not allowing the environment variables to override the
remote credential store. I am not set on either order, but I thought that
typically the more dynamic the value, the higher priority it gets. For
example: Args -> Environment variables -> System properties -> Store data
Finally, we need to be careful with "env." prefixes since Hadoop
> configuration already handles that case (which GatewayConfigImpl extends
> from). Meaning that env.ENVRIONMENT name properties are actually available
> today.
Good point. I didn't realize this. So some other decoration can be used.
So if some property has a value if "env.USER", when querying the Gateway
config for that value, "env.USER" will not be returned. Instead something
like "rlevas" will be?
Rob
On Mon, Feb 25, 2019 at 3:18 PM Kevin Risden <kr...@apache.org> wrote:
> I guess one of the questions that comes to mind is do we need to support
> the environment variable being updated while Knox is running?
>
> I don't know if the environment can be changed from underneath a running
> process. One area that this is also interesting is with Kubernetes/Docker
> and how secrets can be managed.
>
> If environment variables will not be updated while Knox is running, then
> why don't we push aliases provided by environment variables to the
> LocalAliasService. This would avoid having to do special handling for
> environment variable lookups. Basically bootstrap the local alias service
> with the environment variable passwords.
>
> Finally, we need to be careful with "env." prefixes since Hadoop
> configuration already handles that case (which GatewayConfigImpl extends
> from). Meaning that env.ENVRIONMENT name properties are actually available
> today.
>
> Kevin Risden
>
>
> On Mon, Feb 25, 2019 at 3:10 PM Robert Levas <rl...@cloudera.com.invalid>
> wrote:
>
> > Team...
> >
> > I would like to open a discussion on adding a feature to Knox to allow
> the
> > Gateway get a password from the environment as well as the remote and
> local
> > credential stores. This is potentially needed by management consoles,
> like
> > Cloudera Manager, that can create keystores but pass the credentials for
> > them using environment variables.
> >
> > See KIP-13 Environment variables should be usable when looking up
> passwords
> > <
> >
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> > >
> > for
> > more information.
> >
> > The relevant JIRA is KNOX-1794
> > <https://issues.apache.org/jira/browse/KNOX-1794>.
> >
> > Rob
> >
>
Re: [DISCUSS] Environment variables should be usable when looking up passwords
Posted by Kevin Risden <kr...@apache.org>.
I guess one of the questions that comes to mind is do we need to support
the environment variable being updated while Knox is running?
I don't know if the environment can be changed from underneath a running
process. One area that this is also interesting is with Kubernetes/Docker
and how secrets can be managed.
If environment variables will not be updated while Knox is running, then
why don't we push aliases provided by environment variables to the
LocalAliasService. This would avoid having to do special handling for
environment variable lookups. Basically bootstrap the local alias service
with the environment variable passwords.
Finally, we need to be careful with "env." prefixes since Hadoop
configuration already handles that case (which GatewayConfigImpl extends
from). Meaning that env.ENVRIONMENT name properties are actually available
today.
Kevin Risden
On Mon, Feb 25, 2019 at 3:10 PM Robert Levas <rl...@cloudera.com.invalid>
wrote:
> Team...
>
> I would like to open a discussion on adding a feature to Knox to allow the
> Gateway get a password from the environment as well as the remote and local
> credential stores. This is potentially needed by management consoles, like
> Cloudera Manager, that can create keystores but pass the credentials for
> them using environment variables.
>
> See KIP-13 Environment variables should be usable when looking up passwords
> <
> https://cwiki.apache.org/confluence/display/KNOX/KIP-13+Environment+variables+should+be+usable+when+looking+up+passwords
> >
> for
> more information.
>
> The relevant JIRA is KNOX-1794
> <https://issues.apache.org/jira/browse/KNOX-1794>.
>
> Rob
>