Make transport.SetConnection public? about grpc-go

[atollena]

It's likely that we don't want setting the connection in the context to be a public API just to simplify testing of the usage of RBAC interceptors. The functionality to obtain local and peer addresses are otherwise available via the peer package. I do wonder though why the RBAC filter does not simply use the public peer.LocalAddr which is available in the context.

Alternatively, I tried to set up a full stack, but it increases the preparation complexity and make the test slow.

A lot of the tests in grpc-go work like this, so that's the approach I would recommend. You can look at examples in https://github.com/grpc/grpc-go/blob/c04b085930ce33ee83cc3f92dbe7632031e127a9/authz/grpc_authz_end2end_test.go. Each test that starts a client and a server run in less than 1-2 millisecond. There's maybe a bit more boilerplate for setup, but that's enough to justify making this API public, and it'll make the tests less brittle than relying on internal APIs.

[atollena]

@zasweq do you happen to remember why we directly want to use the conn.LocalAddr rather than peer.LocalAddr in the RBAC filter code:

grpc-go/internal/xds/rbac/rbac_engine.go

Lines 223 to 228 in c04b085

	// The connection is needed in order to find the destination address and
	// port of the incoming RPC Call.
	conn := getConnection(ctx)
	if conn == nil {
	return nil, errors.New("missing connection in incoming context")
	}

?

[atollena]

Anyways, I think your best option for your use case seems to be end to end tests that don't rely on how the RBAC filter communicates with gRPC's transport. Let us know if that doesn't work for you, and why.

[Zenithar]

Ok, thank you. I will find another way to build a policy tester without setting up the complete gRPC stack.