search

clusterlink-net / clusterlink

A Gateway for connecting application services in different domains, networks, and cloud infrastructures
https://clusterlink.net
Other
17 stars 18 forks source link

Support for `-capath` path option in addition to `-cacert` #34

Open elevran opened 9 months ago

elevran commented 9 months ago

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 commented 1 month ago

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.