Re: Next version of design and process docs available

White2, James

Thanks Tony.  Am traveling tonight but will take a look and incorporate tomorrow in the copy for review on Wednesday.



From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of espy
Sent: Monday, April 8, 2019 6:12 PM
To: White2, James; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Next version of design and process docs available



On 3/31/19 7:00 PM, White2, James wrote:


Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)


The next version of these docs is available on the Wiki and at the link locations below:

Here are my comments on v6 of the Protecting Secrets document.



 - <p1> 1st sentence: "centralize management" --> "centralized management"

 - <p2> 2nd sentence: "permission need" --> "permission needs"

= inventory of edgex secrets =

 - last bullet, last sentence: "securely store" --> "securely stored"

= secret storage architecture =

 step 1 - the part of the last sentence needs re-wording ("and an ACL that back by Vault...". I'd actually just suggest dropping that part instead.

 step 2

  - Shouldn't this step happen before 1?

  - This should mention that the access token is the master

  - Are there more than one initialization programs (same question for step 3)?

= vault initialization =

 - If the secret store init is written in Go, it's not really a script anymore.  Just sayin...

 - <p2> 2nd sentence:

   - if secrets are passed by command-line, aren't they going to be in source code whereever the command-line is defined? This applies to environment variables too... Why not use a configuration file approach where the init app would read secrets configuration files from a volume and then delete them when initialized?

   - how would someone do this if EdgeX is being deployed via docker-compose? how would someone do this in the snap?

 - <p2> last sentence: What's the use case for being able to generate GUIDs or random strings?

 - <p3> This sentence ("If the credentials need to be updated...") doesn't make sense as written.

= vault master token file protection =

 - I'd suggest a slight re-wording of the first sentence:
    "Today, the Vault master token is stored, without protection, in the file system. In docker deployments this is a shared volume. In snap deployments this this write-able part of the snap."

 - Also note that on a traditional Unix/Linux system this file would be only owner readable via standard MAC, however doing this with docker and shared volumes might be tricky.

 - And a slight re-wording of the second sentence too:
   "In the future, this file needs to be protected with an HSM (e.g. TPM) or similar mechanism."

= org of secrets =

 - <p1> "In general, credentials will be organized under a namespace of v1/secret/edgex/:path"

  - Is the ":" a typo?

  - Is mongodbinit an existing micro service?

  - paths typically start with a "/"

 - <p4> It looks like triggering GUID generation is to just use the value ”xxxxxxxxx-xxxxxxxx-xxxxxxxx”. Does password generation use the same value or is it just a string of 'x' chars? Does the length matter?


We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.


Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.



Jim White

Director, IoT Platform Development Team & Distinguished Engineer

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693



Join to automatically receive all group messages.