How to lower security guards for integration testing?

[lowgear]

Hello!

I am attempting to set up integration tests in my project.
I need to use per-RPC credentials for authorization but I would not like to set up my own root CA and actual SSL in my tests.

During my attempts I have figured out that grpc-go cares about client configuration security and integrity thus preventing me from setting up described configuration (specifically, from using grpc.WithPerRPCCredentials(oauth.TokenSource{...}) together with insecure.NewCredentials()).

What is the recommended way of accomplishing the described behavior in tests?

[purnesh42H]

@eshitachandwani to look as current oncall

[eshitachandwani]

Hey @lowgear, you're correct that using grpc.WithPerRPCCredentials(oauth.TokenSource{...}) with insecure.NewCredentials() is not allowed because gRPC enforces secure transmission of tokens, requiring an underlying secure transport. To work around this, you can use credentials.NewClientTLSFromCert() with a nil certificate pool, like credentials.NewClientTLSFromCert(nil, ""). This creates TLS credentials using the system's default certificate pool, which works with servers that have certificates signed by trusted public CAs.
Let me know if you have any more questions.

[lowgear]

I think I have not described my scenario clear enough. Let me correct myself.

In our project we make tests hermetic as possible. In particular, we set up all the components of the system on localhost during test preparation stage and the endpoint to which the connection is established during the test is a port on localhost too.
The tests are supposed to have reproducible results at any time thus it is not viable to have a certificate stored along with the tests sources as it will eventually expire because it will not be valid longer than the root certificate.
On the other hand issuing a certificate for each tests run does not sound good either.

So, unfortunately, using the system's default certificate pool is not helpful in my particular situation.

If more details are required I will be glad to provide.

[purnesh42H]

@lowgear its not clear what you mean by "it is not viable to have a certificate stored along with the tests sources as it will eventually expire because it will not be valid longer than the root certificate".

Regarding WithPerRPCCredentials, have you tried to look into following example https://github.com/grpc/grpc-go/blob/master/examples/features/authentication ? You can do something similar. Have the certificate stored in a local directory. The certificates used in example are created using openssl and i think its possible to set a long expiry date or no expiry.

You can take a look at other auth mechanisms here https://grpc.io/docs/guides/auth/

[purnesh42H]

@lowgear just checking if you got a chance to try the approach in the example and if you need more clarification or help.

[lowgear]

Okay, I have examined the example you have linked and yes, with such approach I can generate certificates for the purpose of testing.

But basically my question was if I can avoid doing exactly that - that's what I meant by "I would not like to set up my own root CA and actual SSL in my tests" :)

I guess the answer to my exact question is no.

But that brings up the question if such library as grpc-go should not be just inclined towards secure practices (default behaviour is secure but insecure one is achievable with specific set of prarameters) but completely restrict the use of insecure practices. I would not like discuss such question here but that is where it ends up.

[purnesh42H]

Yeah I think you cannot easily and directly achieve true SSL/TLS authentication (with certificate verification) without setting up your own root CA and issuing certificates. I can ask other maintainers if there are workarounds but it would definitely not be recommended for integration tests as they should be close to real world scenarios where a client needs to be able to verify that the server's certificate was issued by a trusted Certificate Authority (CA).

[lowgear]

Well, in our production it is common practice to terminate SSL at L7 balancer and then send unencrypted traffic to the backends.

As far as I know it is well known practice and a valid use of passing credentials over unencrypted connection (but surely only because of the trusted environment).

[github-actions]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[purnesh42H]

@lowgear so the thing is oauth rpc credentials required transport security https://github.com/grpc/grpc-go/blob/master/credentials/oauth/oauth.go#L140 and that's why you are not able to use insecure transport credentials. In addition there is a security level check which checks if a connection's security level is greater than or equal to the specified one.

I tried to comment out these checks and tried the auth example with insecure transport purnesh42H/grpc-go@master...purnesh42H:grpc-go:use-insecrure-with-oauth and looks like that works. So, I think just for your testing you can implement your own custom credentials which doesn't require secure transport credentials and use that with oauth RPC credentials. However, this is not recommended for prod path.

[github-actions]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.