Hey, we're trying to use the SpiceDB Python client against SpiceDB running in our Kubernetes cluster via our service endpoint address, and we're getting this error:

grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
    status = StatusCode.UNAVAILABLE
    details = "failed to connect to all addresses; last error: UNKNOWN: ipv4:10.30.181.203:50051: Endpoint is neither UDS or TCP loopback address."
    debug_error_string = "UNKNOWN:failed to connect to all addresses; last error: UNKNOWN: ipv4:10.30.181.203:50051: Endpoint is neither UDS or TCP loopback address. {created_time:"2023-08-23T14:19:24.347552207+00:00", grpc_status:14}"

From a look at the code (admittedly I'm not too familiar with gRPC), the code is always initializing a secure channel - so maybe the problem is that the Python library doesn't support plaintext connections except on localhost? https://github.com/authzed/authzed-py/blob/6ad60c5a20cd195363381a434efe8d64f76c1e53/authzed/api/v1/__init__.py#L54-L58

I see this reported here too: https://github.com/authzed/authzed-py/issues/89

yea, I'm gonna try to add a cert and see what happens

the gRPC folks pointed us to this experimental API https://github.com/grpc/grpc/blob/v1.57.0/src/python/grpcio/grpc/experimental/__init__.py#L53-L58

how do we use it with the spicedb client?

where did you see the issue has been opened for 3 years?

oh, I didn't lcick and thought you had linked this issue, which I found from Googling the error message: https://github.com/grpc/grpc/issues/22020

I see, jimmy had this one opened https://github.com/grpc/grpc/issues/33618

tl;dr for us right now is that we need to get a cert generated and added to our cert store, I guess?

We had the same issue and ended up with this solution (quite far from being elegant):

class Client(BaseClient): 
    def __init__(
        self,
        target: str,
        credentials: Any,
        options: list[tuple[str, object]] | None = None,
        compression: Any = None,
        use_async_client: bool = True,
    ):
...
        # super ugly way to get the token value from the grpc credentials object
        self.metadata = [
            (
                "authorization",
                "bearer "
                + credentials._credentials._call_credentialses[0]._metadata_plugin._metadata_plugin._access_token,
            )
        ]
...

and then in every call we have this

resp = await client.CheckPermission(
        request=request,
        metadata=client.metadata,
    )

Thanks Alex! We'll give it a try. I'm confused with all of this tbh

can you tell us more about this? do y'all not have a load-balancing layer in your infra that does TLS offloading?

We have an application written in Python and we want to use SpiceDB to handle our authorization, running inside Kubernetes. We have the Operator deploying a SpiceDB cluster, also in the same cluster, with PostgreSQL as a backend. We expect activity on the order of a few thousand queries per second. Right now we're doing performance testing to see whether it's suitable for us. I don't think we're yet at a scale that warrants Dedicated or Self-Hosted (Enterprise) but we're evaluating those options as well - the sticker price and requirement for an enterprise agreement is something we don't want to deal with at this point in time

I appreciate the context! I was more interested on the situation that led you to deploy SpiceDB without TLS and what limited you to do so! I imagine this would be because y'all are addressing SpiceDB via the Kube Service?

yup, right now we're in our initial assessment phase so the focus is on understanding whether SpiceDB will do what we need at the scale we need, and also learning to operate it. all of our communication is within-cluster so we're not worried about things being encrypted. We did end up getting TLS running after all, though it was painful for reasons unrelated to SpiceDB (we just don't do it for other services, everything just uses Istio so encryption between services isn't really required) Getting that gRPC issue fixed would definitely have improved our onboarding experience :)

yeah that was not great, sorry about that!