Good questions.
Looks the API hasn't changed since when it was added in 2014:
https://github.com/Jerry-Xin/hadoop/commit/c79728478caadd8374bce2bc3f466db1da1e3ad1
I'll create a patch to support this, apart from the CLI extension this
looks like super easy to integrate.
Filed jira: https://issues.
Is the Hadoop Credentials API protected by their compatibility guidelines?
If not, can we convince them to support it formally?
On Thu, Aug 25, 2022 at 17:15 Andrew Purtell
wrote:
> We can import the code from our sister Apache project if long term
> dependency and compatibility are concerns. Th
We can import the code from our sister Apache project if long term dependency
and compatibility are concerns. The concerns apply in both directions:
Depend, do not import: Hadoop may break us with a change that we have to
incorporate by updating to a new minimum version probably because of a sec
+1
But I'm still not sure whether we should just use the code in hadoop,
or we should just use the mechanism but write(copy) the code by our
own?
Andrew Purtell 于2022年8月25日周四 22:13写道：
>
> I agree the Credential SPI provided by Hadoop is direct and expedient.
>
> I would ask that a patch integrat
I agree the Credential SPI provided by Hadoop is direct and expedient.
I would ask that a patch integrating it, if this is the selected approach,
should also add support to bin/hbase so “hbase credential …” command line
support is available and identical to that provided by the Hadoop bin script
As Bryan mentioned there's a nice, extensible API already available in
Hadoop, the Credentials API.
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/CredentialProviderAPI.html
I think that would be the quickest and easiest approach to resolve this
problem. Is there any obje
Maybe we could introduce two configs for a password, password-provider
and password-provider-parameter
The default implementation is FileBasedPasswordProvider, where the
parameter is just a location. And also an EnvVarPasswordProvider,
where the parameter is the name of the environment variable.
I agree that it seems insecure to put it directly into the hbase-site.xml.
Another reason is due to the RS UI which (helpfully) can print the entire
site configuration. We’d need to make sure the password is excluded from
that, but better to remove it from site xml altogether.
That said, we alread
In real production deployment, usually we will store an encrypted
password in the configuration file, and then decrypt it after loading,
to actually use it.
And how to get the decryption will depend on the environment. On cloud
VMs, usually you can use an encryption service to decrypt the
password
Hi team,
Netty TLS support is now merged into master and branch-2 branches.
Currently keystore/truststore passwords can only be stored in hbase-
site.xml which is not the best approach from security perspective.
In the docs review Sergey Soldatov mentioned (
https://github.com/apache/hbase/pull/4
10 matches
Mail list logo
