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 <kris...@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 <rle...@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
> > <kris...@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
> <rle...@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
> > > >
> > >
> >
>
