Impact of the secure_train flag.

[nickgautier]

One of our use cases requires disabling mTLS, using normal TLS instead, it also requires dynamic override of the service provider endpoint on the client. This implies:

• Disabling secure_train on the server, since SSL termination hapens at ingress.
• Overriding fed_client.json on the client. Since the original fed_client.json is signed, this doesn't work without secure_train=false.
• Using credentials from well known CA's on the client instead, adding a 3rd mode to the aio_grpc_client.
  Our goal is to maintain as much security as possible whilst achieving our requirement. To that end we would like to understand the impact of setting secure_train=false.
  To our knowledge this means:
• Task is still validated: server & client project name need to match
• Client token is still checked when registering new clients
• Client certificate is no longer checked

We'd be keen for information on how this weakens the system, what we should look out for. Ultimately we would like to stay in secure mode, whilst only overriding the minimum amount of functionality, scoped to mTLS. If there's a way of achieving that, we'd be happy to hear about it.
Thank you!

[chesterxgchen]

@nickgautier notice no one has respond this yet.

To help better understand your end-goal of the use cases, could you elaborate why do you need to "disabling mTLS, using normal TLS instead, it also requires dynamic override of the service provider endpoint on the client " ?

[chesterxgchen]

@yanchengnv

[yanchengnv]

@nickgautier , thanks for the question.
Currently, mTLS is required if secure_train is set to true to ensure that both client and server can trust each other. In one-way TLS, in theory, any one can connect to the server without being provisioned. Client token is just a quick way for the server to identify the session after authenticated. It does not add security.

If secure_train is set to false, then all communication will be done in the clear - no SSL is used at all.

Currently all certs are self-signed by the Provision system. We have been thinking about adding the support to use 3rd-party CA, but it's not implemented at the moment.

Since your requirement is somewhat inconsistent with our security model, I'm not sure it should be implemented.

However, you can do it yourself by providing your own communication driver that allows the "secure_train" to be set to False while doing your own regular TLS. In fact, you can write your driver to achieve any requirements you have. If you need guidance on how to write custom comm driver, we'd be happy to help.