Re: [Edgex-tsc-core] Security Enablement

Jacob Blain Christen
 

I have an open question to Trevor in Slack DM as to what "security=on" would mean on a per service basis but my concern with this proposal is that security is not simply turned on, it is more an assessment of a number of sometimes-orthogonal, granular configurations and whether or not the system has enough information to make use of them in various contexts. Security isn't a feature flag it is more of a feature matrix.

So, if "security=on" means obtaining secrets from Vault instead of local filesystem or Consul (as per DM with Trevor) then a "secure" installation of an EdgeX Service is one that has configured its secret provider/source to be Vault. This formulation is descriptive whereas "security=on" is prescriptive. AKA "if you wish to configure this service to be secure then configure it to get secrets from Vault or some other secure source"

On Mon, Aug 12, 2019 at 1:17 PM espy <espy@...> wrote:

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?

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

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.


Regards,
/tony


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA    



--
Jacob L. E. Blain Christen
T: 443-255-9975

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