Re: [Edgex-tsc-core] Security Enablement


espy
 

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

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.

But if we consider "security" in this context as integration with Vault, it's not that it was "off" for Edinburgh, it wasn't even implemented yet.


Also, if we disable vault integration, where will the services read their secrets from, their local configuration.toml files?


Finally, I'll note that we decided that by default for Fuji, the main docker-compose will spin up all of the security containers, and this is a non-backwards compatible change that was deemed acceptable...


/tony


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.


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.