gwynlionhart opened a new issue, #4595:
URL: https://github.com/apache/accumulo/issues/4595
**Describe the bug**
When you setup a CredentialProvider JCEKS file with an alias
"ssl.truststore.password" for use in the accumulo-client, then Accumulo will
not be able to find and retrieve that value from the JCEKS. I got a bit lost,
but I think what was happening was that the ClientConfConverter class was only
ever looking for the server property "rpc.javax.net.ssl.trustStorePassword" and
not the client-specific value. So long as I put
"rpc.javax.net.ssl.trustStorePassword" as an alias into the JCEKs file I didn't
have an issue.
**To Reproduce**
Steps to reproduce the behavior (or a link to an example repository that
reproduces the problem):
1. Setup an accumulo-client.properties with basic info but importantly ssl
enabled, a credential provider specified, and a ssl.truststore.path
```
#Whatever you have for instance.name and instance.zookeepers in
accumulo.properties
instance.name=instance
instance.zookeepers=zookeeper:2181
#When defined, Accumulo will try to retrieve matching properties out of the
jceks
general.security.credential.provider.paths=jceks://file/path/to/accumulo/conf/accumulo.jceks
auth.principal=accumulo
auth.type=password
auth.token=password
#SSL Configuration
ssl.enabled=true
ssl.truststore.path=/path/to/accumulo/conf/ssl/truststore.jks
```
3. Launch Accumulo itself with SSL enabled, then try to connect to Accumulo
shell with the above accumulo-client.properties
4. See error
```
[root@accumulo scripts]# accumulo shell --config-file
accumulo-client.properties
2024-05-23T13:27:21,382 [clients.ClientServiceThriftClient] WARN : Failed to
find an available server in the list of servers: [ssl:accumulo:9997 (120000)]
```
With java debugging enabled you will see that it is giving an empty password
to the truststore. And if you debug on line 172 of ClientConfConverter.java and
click play a few times to see the properties it's looking for, you will find
that it is only searching the for properties like
"rpc.javax.net.ssl.trustStorePassword"
**Expected behavior**
Entering Client properties should work in the CredentialProvider lookup in
the same way that we are able to use the Client properties in the
accumulo-client.properties file. I'm unsure if that's feasible if the list of
properties supported by Credentialprovider is defined by Hadoop and not
Accumulo.
In which case, another (easier) solution would be to update the list of
properties in the documentation to include a caveat about CredentialProviders
and how the property name conversion thing means you need to put the server
property into the JCEKS. For example, in the Description column of
"ssl.truststore.password" you could include "Note: if protecting this property
in a CredentialProvider specified in
'general.security.credential.provider.paths', then you must use the property
"rpc.javax.net.ssl.trustStorePassword" inside of the CredentialProvider."
Semi-related when it comes to properties documentation, but I think there
are a few server properties you _do_ need to specify in
accumulo-client.properties that aren't documented on the client properties
page. For example, if Accumulo is using TLSv1.3, then the
accumulo-client.properties file _has_ to specify
"rpc.ssl.client.protocol=TLSv1.3" though that property is only listed in the
server properties page, otherwise you get infinite
"2024-05-23T13:34:54,194 [transport.TIOStreamTransport] WARN : Error closing
output stream.
java.net.SocketException: Connection or outbound has closed
" stack traces. You have to put the property in both server and client
property files if the value isn't the default TLSv1.2, or else
"accumulo-cluster stop" will throw a similar error. Oh, and currently the
client properties don't mention that general.security.credential.provider.paths
is a supported property either, though I'm very grateful that it is supported
still.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
