feat(core): added support of the TLS certificates along with x-token authorisation token for the gRPC connection #3954
Conversation
vgonkivs
requested review from
renaynay,
Wondertan,
walldiss and
cristaloleg
as code owners
vgonkivs
added
kind:break!
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3954 +/- ##
==========================================
+ Coverage 44.83% 45.36% +0.52%
==========================================
Files 265 309 +44
Lines 14620 21999 +7379
==========================================
+ Hits 6555 9980 +3425
- Misses 7313 10944 +3631
- Partials 752 1075 +323 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
nodebuilder/core/tls.go
Outdated
| certPath := filepath.Join(tlsPath, cert) | ||
| keyPath := filepath.Join(tlsPath, key) | ||
| exist := utils.Exists(certPath) && utils.Exists(keyPath) | ||
| if !exist { |
| if err != nil && !errors.Is(err, os.ErrNotExist) { | ||
| return nil, nil, nil, err | ||
| } | ||
| opts = append(opts, state.WithTLSConfig(tlsCfg), state.WithXToken(xtoken)) |
state/core_access.go
Outdated
| authInterceptor := func(ctx context.Context, | ||
| method string, | ||
| req, reply interface{}, | ||
| cc *grpc.ClientConn, | ||
| invoker grpc.UnaryInvoker, | ||
| opts ...grpc.CallOption, | ||
| ) error { | ||
| ctx = metadata.AppendToOutgoingContext(ctx, "x-token", ca.xtoken) | ||
| return invoker(ctx, method, req, reply, cc, opts...) |
vgonkivs
force-pushed
the
tls_for_grpc
branch
from
6c08a44
to
1901d84
Compare
| @@ -19,13 +19,23 @@ type Config struct { | |||
| IP string | |||
| RPCPort string | |||
| GRPCPort string | |||
| // TLSEnabled specifies whether the connection is secure or not. | |||
| // PLEASE NOTE: it should be set to true in order to handle TLSPath and/or XTokenPath. | |||
| TLSEnabled bool | |||
There was a problem hiding this comment.
Do we need this if we just provide a TLSPath?
There was a problem hiding this comment.
Yes, we need it for a use case when we have to provide an empty config.
| coreRPCFlag = "core.rpc.port" | ||
| coreGRPCFlag = "core.grpc.port" | ||
| coreFlag = "core.ip" | ||
| coreRPCFlag = "core.rpc.port" |
There was a problem hiding this comment.
if you rebase, you won't need this anymore and also won't need to specify grpc in the name of the flag
so core.grpc.tls.path --> core.tls.path and same for xtoken
I'd propose merging it inside api breaks as we have one more PR related to the grpc connection. So, imo it's better to keep everything in one place. + I'm going to open one more PR based on the @rach-id changes to unify grpc clients. Merging current PR to main will block clients unification |
vgonkivs
changed the title
|
I was reviewing the PR and noticed that we're configuring client certificates, which seems to be for setting up mutual TLS (mTLS). My understanding is that we only need to verify the server's certificate since we'll be sending an x-token authorization header for client authentication. Do we really need client certificates on the client side in this case? Also, I didn't see any setup for root CA certificates, which are necessary when dealing with self-signed or custom certificates—a pretty common use case. Without specifying the root CA, the client won't be able to validate the server's certificate. Could we adjust the implementation to focus on server-side certificates and include support for custom root CAs? What are your thoughts? |
|
We agreed with @walldiss in DM that we don't want to keep any certificates for now(as they were out of the scope of the initial request) |
vgonkivs
force-pushed
the
tls_for_grpc
branch
from
4436a9f
to
3f176d5
Compare
vgonkivs
force-pushed
the
tls_for_grpc
branch
from
3f176d5
to
3ce38b2
Compare
The PR introduces breaking changes to the Core config. It extends the config with 3 additional fields that allow for configuring a secure grpc connection:
Three additional flags have been added to configure these fields.