> > 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 <[email protected]> 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 <[email protected]> > 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 > > >
