I know the discovery mechanism employs aliases for usernames also. On Tue, Feb 26, 2019 at 9:03 AM Robert Levas <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > <[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 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 > > > > > > > > > > > > > > > > > > > > >
