feat(core): added support of the TLS certificates along with x-token authorisation token for the gRPC connection

[vgonkivs]

The PR introduces changes to the Core config. It extends the config with 2 additional fields that allow for configuring a secure grpc connection:

• TLSEnabled - specifies whether the connection is secure or not;
• XTokenPath - the path to the directory with JSON file containing the X-Token for gRPC authentication.

Three additional flags have been added to configure these fields:

• core.tls - allows to configure a secure connection. By default: false
• core.xtoken.path - allows to set an authorisation token. Should be passed along with the core.tls flag

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 31.48148% with 74 lines in your changes missing coverage. Please review.

Please upload report for BASE (feature_branch_grpc@941dead). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
state/core_access.go	34.61%	30 Missing and 4 partials ⚠️
nodebuilder/core/tls.go	0.00%	24 Missing ⚠️
nodebuilder/core/flags.go	60.86%	7 Missing and 2 partials ⚠️
nodebuilder/state/core.go	22.22%	6 Missing and 1 partial ⚠️

Additional details and impacted files

@@                  Coverage Diff                   @@
##             feature_branch_grpc    #3954   +/-   ##
======================================================
  Coverage                       ?   45.20%           
======================================================
  Files                          ?      309           
  Lines                          ?    22179           
  Branches                       ?        0           
======================================================
  Hits                           ?    10025           
  Misses                         ?    11054           
  Partials                       ?     1100           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[renaynay]

@vgonkivs this isn't a breaking change bc those fields are purely additive - nothing about validation logic for config has changed so no worries to base it on api-breaks. You can re-base it on main actually.

[vgonkivs]

@vgonkivs this isn't a breaking change bc those fields are purely additive - nothing about validation logic for config has changed so no worries to base it on api-breaks. You can re-base it on main actually.

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

[walldiss]

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?

[vgonkivs]

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)

[cristaloleg]

SGTM

[renaynay]

happy with it, just some nits.

[walldiss]

Looks good and simple. Additionaly it might be worth to add grpc layer unit tests for:

• tls enforced mod
• x-token can be retrieved by server