This adds a new Helm value named agentTLSMode, with two supported values:
system-store, the default: in this mode, the Fleet agent behaves as it has so far, trusting certificates signed by any CA installed in the system store when registering against an upstream cluster.
In this mode, Fleet will also ignore a configured CA, if the system trust store is sufficient.
strict, to ignore the system store during the cluster registration process
Updating that value in the fleet-controller config map triggers redeployment of the Fleet agent, on the upstream cluster and on downstream clusters which had been registered following a manager-initiated process (as would typically be the case when importing clusters through Rancher). This does not work for agent-initiated registration.
Open points:
bypassing the system-wide CA store is done by setting environment variables SSL_CERT_FILE and SSL_CERT_DIR, mentioned here, to /dev/null. This is admittedly a bit hacky. Is there a cleaner way, keeping in mind that Fleet agent containers run with a read-only filesystem?
Refers to #2171
This adds a new Helm value named
agentTLSMode, with two supported values:system-store, the default: in this mode, the Fleet agent behaves as it has so far, trusting certificates signed by any CA installed in the system store when registering against an upstream cluster.strict, to ignore the system store during the cluster registration processUpdating that value in the
fleet-controllerconfig map triggers redeployment of the Fleet agent, on the upstream cluster and on downstream clusters which had been registered following a manager-initiated process (as would typically be the case when importing clusters through Rancher). This does not work for agent-initiated registration.Open points:
SSL_CERT_FILEandSSL_CERT_DIR, mentioned here, to/dev/null. This is admittedly a bit hacky. Is there a cleaner way, keeping in mind that Fleet agent containers run with a read-only filesystem?