Re: Security WG meeting tomorrow after the TSC Call (10am central)
Zeng, Tingyu <tingyu.zeng@...>
Please see my comments inline below.
From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of Malini Bhandaru via Lists.Edgexfoundry.Org
Sent: Wednesday, March 27, 2019 3:15 AM
To: White2, James; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)
Thank you Tingyu and Jim for the secrets storage v4 document.
A few comments/questions:
1) Would you please include a sample vault master token file.
[Tingyu] a sample master token file can be found on github security-api-gateway project here: https://github.com/edgexfoundry/security-api-gateway/blob/california/core/res/resp-init.json
2) What is the auth: null in the json response from a rest API call?
[Tingyu] this is the auth method that can be customized to protect the individual resource other on top of the master token. Default it is null as we haven’t defined it yet.
3) While ACLs are not checked in Edinburgh, would it make sense to have some stub code in there that
tests ACLs and returns trivially true to get the flow in place?
[Tingyu] the ACL will be implemented in the secret store ( Vault) side, either HCL or policy file. We will include some sample files/configuration later.
4) How do we anticipate to use the ACL? Might it be which microservice can make what REST call on another microservice?
[Tingyu] ACL we are referring here is for retrieving secret from secret store ( Vault). Communication between microservice is still in the road map, we have a couple of options like sidecar etc.
5) Is the namespace to microservice mapping one-to-one?
[Tingyu] yes it is for this current implementation.
6) Why do the namespaces need to be secret?
3. Define the secret namespaces and share the namespace definitions with the individual consuming micro service or init scripts.
[Tingyu] A better description would be “Define the namespace for the credentials and sensitive data for individual microservice”. The namespace itself is not secret, it needs to be published to the consumers.
7) Looks like the flow chart figure with steps 1, 2, .. 4.1 .. 5 is duplicated. Why?
[Tingyu] need more details ..
8) What does secret store namespace description look like?
[Tingyu] If I understand it correctly, the namespace it self-explained, something like this: v1/secret/edgex/devicemodbus
From: <EdgeX-TSC-Security@...> on behalf of "White2, James
via Lists.Edgexfoundry.Org" <James.White2=dell.com@...>
Apologies in that it has taken me sometime to get organized as the temporary chair of this working group. However, we have been working in the background to try to organize the necessary work for the Edinburgh release. Additionally, we have been talking to members of Intel and David Ferriera about roadmap items (importantly what has to be explored for Fuji). In tomorrow’s meeting, I’d like to share with you some of this work and get your reaction.
Specifically, the agenda for tomorrow includes:
1) Edinburgh Release Securing EdgeX Secrets (securing the Vault Master token and database username/password at a minimum)
2) Providing a means to report/react to security issues (per recent CVE discussions)
3) Planning/working roadmap and Fuji release – getting out front of that release starting now (Intel helping to drive)
Please see and review the attached documents in advance of tomorrow’s meeting to discuss items #1 and #2
Look forward to the call and chatting with you all.
Distinguished Engineer, IoT Platform Development Team Lead
EdgeX Foundry Technical Steering Committee Vice Chairman
Dell Technologies | IoT Solutions Division
Office +1 512-723-6139, mobile/text +1 612-916-6693