https://authzed.com logo
Join Discord
Powered by
Wondering if anyone else has run into this issue b...
# spicedb
c
Wondering if anyone else has run into this issue before. We have a SpiceDB server running on a kubernetes cluster and when using the Java client to talk to it, we get a strange TLS error, but when using the 
zed
client, things work fine. For some more context, I have the SpiceDB container port forwarded to my machine so I'm running the Java client and the 
zed
client from the same place, to the same port. I have configured the client exactly how this is configured: https://github.com/authzed/authzed-java/blob/2a2cbb53334a50fdb6eaa1472973b12557bc2756/examples/v1/App.java#L42-L54 And here is the error
message
j
I'm not super familiar with Java, but it looks like you might not have configured TLS for the client. I'm basing that on this line from your stack trace:
Copy code
Caused by: io.grpc.netty.shaded.io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 000006040000000000000500004000
Looks like the example is using TLS though.
c
That's what I thought too, but like I mentioned, I configured the client exactly how the client in the example is set with 
.useTransportSecurity()
j
grpc-java docs seem to imply that you can even forgo that method call in the builder and it should default to using TLS
let me see -- there weren't mature channel credentials APIs last I checked IIRC
c
Do you happen to know how to pass those into the ChannelBuilder?
I'm looking around now
I tried another tact this morning and still running into issues. Instead of using a SpiceDB instance on our cluster, I spun one up locally and tried reading/writing a schema. Similar errors attached
message
This is with building the client with and without 
useTransportSecurity
j
Are you using a CA that is in the roots in the client environment?
c
No, but we are using Netty, and I wonder if that is causing some of the issues. Errors seem similar to https://github.com/grpc/grpc-java/pull/7476 https://github.com/grpc/grpc-java/issues/8605
s
We haven't tested the client using netty so there could be an issue we haven't encountered yet. You may have already seen this but have you tried the example setup using netty in the grpc docs? https://grpc.io/docs/guides/auth/#with-server-authentication-ssltls-5
If that doesn't work, I'll try our example with netty to try and repro
c
I haven't, I just came across those issues with netty and had to run to an appt this morning. I'll give those docs a shot, thanks
Still getting the same issues with the TLS channel credentials they mention.
Copy code
ManagedChannel channel = Grpc.newChannelBuilder(
        "myservice.example.com:443", TlsChannelCredentials.create())
    .build();
I have a feeling there's an underlying issue because using a plaintext connection is landing this error:
y
so your server is set up as TLS and you need to get your client speaking TLS as well?
c
Thanks for the question, that caused me to re-check everything. I mentioned above that I switched to testing a local SpiceDB because I wanted to rule out issues with the port-forwarding, if that was causing weirdness. I thought that the default https://docs.authzed.com/spicedb/installing#docker was using plaintext, but it doesn't seem to be (is there a list of arguments for the server to start with TLS or not?). Unsurprisingly, using a plaintext client was not working with this local image. So I switched my local grpc-java client to use plaintext, and then started using the port which is setup to talk to our SpiceDB server on our cluster and it all worked. We specifically set it up without TLS, just like this example: https://github.com/authzed/examples/blob/aa1d799ee69ba24956f23081bd9c2316d8793ce9/kubernetes/example.yaml#L84-L106. I still am unable to get the client to work with TLS, but that isn't a blocker at this stage for us.
s
Glad you're unblocked for now. We'll integrate netty and try to get a java example using TLS published
PreviousNext
Powered by