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