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 creden
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
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
>
> 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 po
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 us
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 furt
>
> 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 valu
I know the discovery mechanism employs aliases for usernames also.
On Tue, Feb 26, 2019 at 9:03 AM Robert Levas
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