Design decision for storing certificates, private keys, passwords

[sudhamani-hcl]

Hi Team,

I have come across the below two services:

1. Application service provided at this link https://github.com/edgexfoundry/edgex-examples/blob/main/application-services/custom/cloud-export-mqtt/res/aws/configuration.yaml
2. device-mqtt service provided at this link link: https://github.com/edgexfoundry/device-mqtt-go/blob/main/cmd/res/configuration.yaml

In the cloud export configuration file there is the provision to provide MQTT related passwords, private key and certificates.

In this regard, I have two queries here:

1. If we take certificate based secure communication, why do we need to mention private key in the configuration file?
   If at all private key is needed,
2. We should get it from secret store instead of providing from configuration file?
   Is my understanding correct? Any help would be appreciated!!

Thanks,
Sudhamani

[bnevis-i]

• If we take certificate based secure communication, why do we need to mention private key in the configuration file?
  If at all private key is needed,

On the client side, both a certificate and private key are required. The certificate is used to identify the client to the server by providing the public key that the client will be using, as well as a digital signature on the certificate, issued by a signer that the server trusts, to indicate that the client client is authorized to connect. The corresponding private key is also required to prove the client's identity.

There are standards that bundle the certificate and private key into the same data structure, for example, .PFX, but the more general assumption is that you have one blob that is the certificate, and another blob that is the private key. Most open source products do it this way.

• We should get it from secret store instead of providing from configuration file?
  Is my understanding correct? Any help would be appreciated!!

I totally agree with that, and it does work that way when EdgeX security is enabled. But there are use cases where EdgeX adopters don't want to run with the secret store present, and therefore a fallback mode "InsecureSecrets" allows these values to provided via configuration, because although the EdgeX security features may not be enabled for EdgeX, the upstream may still require them.

[bnevis-i]

Please see the ADR that created InsecureSecrets for more information: https://docs.edgexfoundry.org/2.3/design/adr/014-Secret-Provider-For-All/ In your case, you want to use "service exclusive secrets" stored on the EdgeX secret store.

[sudhamani-hcl]

Thank you @bnevis-i. It clarifies our queries. I am closing this discussion.