Problem Statement
- The sensitive information, like datastore credentials, WiFi Passwords etc., are in clear-text format inside the configuration blob, received from EVE Controller. The sensitive information is exchanged between agents in the EVE node, as is through pubsub channel.
- The sensitive information should be in encrypted format inside the configuration blob for EVE node during the transit and at rest in pubsub storage.
- The sensitive information exchange between the EVE Controller and EVE Node should be encrypted end-to-end.
Proposed Solution
a) For protecting the sensitve blocks of configuration, a symmetric key (AES-256) will be generated by the EVE controller, for every sensitive block of configuration. (e.g. data store credentials, WLAN credentials, cloud-init etc). It is up to the EVE controller to decide if it wants to use the same key for all the blocks or dedicated key for each one of them.
b) Controller can also decide to change the symmetric key(s) periodically, as per user defined policies, which is beyond the scope of this document. The only requirement here from EVE is that, EVE is given the encrypted configuration blobs along with the information to build the symmetric key required to decrypt the corresponding blobs.
c) EVE controller will wrap/seal the symmetric key with device certificate of the EVE node, before sending it across to the EVE node.
d) The senstive configuration stays in encrypted format on disk (i.e. pubsub), and will be decrypted on demand by the end consumer module while processing the configuration.
e) To decrypt the configuration from, the consumer module(e.g. downloader) will unwrap/unseal the symmetric key with the help of TPM-Mgr (using standard go-tpm APIs), and construct the symmetric key first, and then use the symmetric key to decrypt the sensitive config blob, using software crypto tools (e.g. openssl or go crypto/ package)
