Re: [Edgex-tsc-core] Security Enablement


Malini Bhandaru
 

Inline under Trevor’s comment

 

From: <EdgeX-TSC-Core@...> on behalf of "Trevor.Conn via Lists.Edgexfoundry.Org" <Trevor.Conn=dell.com@...>
Reply-To: "Conn, Trevor (EMC)" <Trevor_Conn@...>
Date: Monday, August 12, 2019 at 1:36 PM
To: "espy@..." <espy@...>, "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>, "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: Re: [Edgex-tsc-core] Security Enablement

 

See italicized responses to Tony's email inline below.

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: Tony Espy <espy@...>
Sent: Monday, August 12, 2019 3:17 PM
To: Conn, Trevor; edgex-tsc-core@...; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-core] Security Enablement

 

[EXTERNAL EMAIL]

On 8/12/19 12:20 PM, Trevor.Conn@... wrote:

Hi all -- I posted a follow up to last week's Core WG discussion in the #core Slack channel w/r/t security enablement. It didn't get much traction so I'm reposting it here in order to hopefully facilitate some discussion prior to this week's Security/Core WG calls.

 

Per the discussion in the Core WG call this morning regarding what is controlled under semantic versioning -- We have the question of security enablement. We would like for security to be enabled by default in Fuji. The user will have to opt out of security as of the Fuji release and we need to provide them a mechanism to do that. I'm thinking an environment variable is the best way to do that and not a command line flag.

Is this on a per-service basis? If so, what exactly is being enabled/disabled right now?

 

[TC] It could certainly be per service. Currently since there's no integration at all with Vault, I'd personally consider security disabled.

We can't use a command line flag to turn security off because in Edinburgh it's already effectively off and we'll be changing the default in Fuji -- which isn't backward compatible.

Why isn't it backwards compatible? Couldn't you just add a new option like "--security=off" (although this makes me cringe just a little bit)? It seems to me by doing so, you're not breaking any existing usage...

 

[TC] The point I was making was that if we consider security as off by default for Edinburgh, it must also be so for Fuji. So adding a cmd line flag to turn it off would imply the default was "on"...which would be the reverse of what it currently is and thus non-backward compatible.

I propose we add an environment var like EDGEX_SECURITY=ON that all of the containers / Snap would be aware of. If the var isn't present, then security is disabled, which seems to me like a backward compatible solution. This can be set in the relevant docker-compose file targeting security enablement and I'm sure it's trivial in the Snap. Thoughts?

If there's security logic implemented in a service, I'd rather see a command-line switch or environment variable to explicitly disable it rather than the other way around.

 

[TC] I'm cool with that provided the community can align on the points above w/r/t what we consider the current default. Maybe we don't care what it is (or isn't) in Edinburgh and just chart the course for Fuji.

[MKB] Please let us keep security on by default, someone who disables it must be someone who knows what they are doing. Jives with Tony opinion and likes Trevor’s “chart course for Fuji”

 

Regards,
/tony

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    

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