Support for -capath path option in addition to -cacert

[elevran]

At the moment, ClusterLink uses statically embedded certs and keys, and these are signed by the same CA. In a multi-cloud environment, these could be multiple root of trust, and each gateway would be given certs/keys signed by different root of trust. This means ClusterLink would need to make use of one, or more likely, multiple CA bundles as input. For this reason, tools such as openssl supports both -CApath as well as -CAfile. Is there plan to add this support for ClusterLink?

in the meantime, can use a workaround to deal with multiple CA bundles. As Go can process multiple certificates in a single PEM file (e.g., https://gist.github.com/laher/5795578) - we can take a concatenation of multiple CA certificates in a single file as an intermediate solution. This (bundle in a single file) is something that some Linux distributions also do.
A support for -CApath might still be preferred if we ever want to support dynamic adding and deleting peers/fabrics in the future. Having a directory of CA files rather than having to manage a concatenation of CA files is much easier.

The workaround has been confirmed to work with the Go data plane but has not been tested with Envoy. We may need a control plane change to configure multiple root CA's to Envoy (e.g., via the repeated TlsCertificates entry).

[elevran]

Since we're moving to use of SDS, these flags should be added to the control plane and communicated to the data plane over SDS on updates.

The --cacert CLI flag is no longer in use. Instead, we use fixed paths for (1) peer cert, (2) peer key and (3) CA cert.
The first step might be to re-enable the --cert, --key and --cacert CLI flags, defaulting to the current hard-coded paths.
This would keep the current behavior (flags are not specified by default, hence assigned the default values).
The next step would be to add a --capath, collect all certificate PEM files from it, and add them to the x509.CertPool used.
It's ok to assume that the CA certificates do not expire during the lifetime of the pods.

• Side note: should ensure code checks and reports on missing files in set path, no CA certs found in path, etc.