Re: Next version of design and process docs available


White2, James
 

Thanks Tingyu.  I’ll try to incorporate Tony’s input and any of your applicable responses tonight and have it available for review tomorrow.

 

From: Zeng, Tingyu
Sent: Tuesday, April 9, 2019 9:01 AM
To: espy; White2, James; EdgeX-TSC-Security@...
Subject: RE: [Edgex-tsc-security] Next version of design and process docs available

 

Tony,

 

Thanks for the comments. I am trying to answer some questions in your previous email 

 

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

 

Answer: the purpose is to create username/password that are hard to guess - once they are created they will be staying in the secret store and the only way to access is through the REST API or command line interface. I will explain more in this weeks security group meeting.

 

   - 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?

Answer: We are trying to eliminate the cases that keep the password/credential in plain text in the system so that anyone can read it. 

 

 

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

  - Is the ":" a typo?

Answer: This is not a typo. It means a path that can be decided later based on the individual micro service. Some other options to use here would be something like {:path}. 

  - Is mongodbinit an existing micro service?

Answer: Yes it is, and here is the name of the repo is docker-edgex-mongo. 

 - <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?

Answer:  In the example this is GUID that represents a unique resource in the secret store. Using GUID as a password has its disadvantage. We will discuss more in this week's security group meeting about the options. 

 

 

Thanks

Tingyu

 

 

 


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

[EXTERNAL EMAIL]

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

All,

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:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

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

/tony

---

 - <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?

 

 

https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

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.

 

Thanks,

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

james_white2@...

 

Join EdgeX-TSC-Security@lists.edgexfoundry.org to automatically receive all group messages.