...
- 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
...
- The sensitive configuration blocks for an EVE-node, not all-inclusive, are data store credentials, WLAN credentials, cloud-init (containing Azure/AWS credentials etc.)
- Every sensitive configuration blok will contain a set of attributes storing the encryption configuration (symmetric key value in cypher text, key size and encryption algorithm .e.g., "keySize": "256" bits, "algorithm": "AES-256" etc.)
- EVE Controller will generate a symmetric key for every sensitive block of configuration.
...
- Alternatively, The EVE controller can use the same key for all the sensitive configuration blocks.
- EVE Controller will use symmetric Key(s) to encrypt these above mentioned sensitive configuration blocks
...
- , using standard encryption methods ( AES-256 etc.) using standard software ctypt tools ( e.g. openssl or, go crypto etc.)
- EVE controller will wrap/seal the symmetric key(s) using device certificate of an EVE node, for each sensitive configuration block, before posting them to the EVE-Node.
- These symmetric key(s) generation/rotation can be driven by
...
- user defined policies, which is beyond the scope of this document.
...
- EVE controller can also generate these symmetric keys, while constructing the configuration blob for an EVE node, and discard them after that.
- Inside EVE-node, the
c) EVE controller will wrap/seal the symmetric key with device certificate of the EVE node, before sending it across to the EVE node.
...
- senstive configuration stays in encrypted format on disk (i.e., pubsub), and will be decrypted on demand by the end consumer
...
- .
...
- The end 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
...
- etc.)