Re: [Edgex-tsc-core] Security Enablement


OK, having a more granular level of capability toggle is fine with me. My whole point in creating this thread was to start a discussion rather than recommend an implementation. The Core WG is starting down a path for integrating the new security services as found in edgex-go, and we have to define what the particulars are. I'd recommend this be an agenda item on the Security WG call tomorrow. If there isn't time, then I'll make it an item in the Core WG on Thursday.

Two things need to be defined as requirements

  • Use of environment variables sounds palatable to the group. Do we also want to support equivalent cmd line flags and config settings? What if they conflict, which takes precedence? What are the specific names of each?
  • Based on the discussion below, we have a setting to enable/disable secrets. What other levels of granular control exist in our Fuji solution?

It also sounds like we're saying we are free to create a solution for Fuji without any past constraints since Fuji will entail the first full integration of security services.

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

From: Gardner, Doug <Doug.Gardner@...>
Sent: Tuesday, August 13, 2019 6:33 AM
To: Ian Johnson; Bhandaru, Malini (VMware)
Cc: Conn, Trevor; espy@...; EdgeX-TSC-Core@...; EdgeX-TSC-Security@...
Subject: RE: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement


Well stated and explained Ian.  I agree with you and thanks for writing it up.





Doug Gardner


Office: 813.559.6617


From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of Ian Johnson
Sent: Monday, August 12, 2019 9:29 PM
To: Malini Bhandaru <mbhandaru@...>
Cc: Conn, Trevor (EMC) <Trevor_Conn@...>; espy@...; EdgeX-TSC-Core@...; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement




Hi folks, 


I would like to echo Jacob's point about security not being a binary thing and being more like a matrix. I proposed something in slack about having that environment variable not being a binary switch but rather being based on the feature that is actually wanting to be enabled/disabled. For example, it sounds like for now this environment variable will only be controlling whether or not a given security service will use vault for getting it's database access credentials or not. However there are other security minded things that we will be turning on by default when we say that "security is on by default" for Fuji such as turning on the security-api-gateway. There may eventually be more configuration that we want turned on by default with the reference distribution of EdgeX, and so I think it's wise to make this not a binary thing but make it work in a generic way that will support turning on/off other features.


For now, I think it's okay to have an environment variable control whether or not core services will use vault for accessing database credentials, though I think that we should implement a "sensible default" here where if someone doesn't specify the environment variable then they get the default security features turned on and only if they want them turned off will they need to specify something additional. This is important for deployments where folks may not know to go looking for all of these options and so we want this to work in a secure manner with as little configuration as possible. I also would prefer to see a configuration.toml key for controlling this behavior with a command line flag as well (with the environment variable overriding the command line switch, and the command line switch overriding the configuration file).


As such, I think a better name for this specific feature would be something like DISABLE_USE_SECRET_STORE, or as a command line flag --disable-use-secret-store and a configuration.toml key DisableUseSecretStore. That keeps it obvious what is being turned off and won't scare away users/admins the way --security=off would. It also allows a more fine grained control over what new security features we might add that we want to turn on by default. I think this environment variable needs to be per-service, how would docker-compose read an environment variable to control what services to startup and such when it launches containers? We would have a similar problem in the snap that we can honor environment variables from the user's session when launching a specific service or app (though this itself is difficult since all these are systemd services in the snap), but we cannot honor or check environment variables when installing the snap to modify how the default installation of the snap works. 


I'd also just like to address the point about turning security on by default being a backwards incompatible change. IMHO, I don't think this is a backwards incompatible change, because we are not removing or otherwise changing how EdgeX responds to a user's input with the system the same way that we would be if we removed an API endpoint. In my mind, what we're really adding is a new feature in the reference packaging of EdgeX, not removing any previous functionality. Since the reference packaging formats of docker and snap both include the database as well as the security secret-store (Vault), I don't think there's really any user input that would be broken by this change. If instead we required the user to install and configure these dependencies (such as Vault) manually in order to use EdgeX or changed how EdgeX interacts with a user-managed version of the database, that would be closer to a backwards incompatible change because a user-managed resource would need to be modified to work with a new release of EdgeX. Finally, even if we did consider this a breaking change I think we as a community have decided that security will be on by default for Fuji, so even if this is a breaking change I think it's more important for us to have security on by default than it is for us to not break that specific compatibility change. 





On Mon, Aug 12, 2019 at 5:34 PM Malini Bhandaru via Lists.Edgexfoundry.Org <> wrote:

Inline under Trevor’s comment


From: <EdgeX-TSC-Core@...> on behalf of "Trevor.Conn via Lists.Edgexfoundry.Org" <>
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
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



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”




Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Round Rock, TX  USA

Join to automatically receive all group messages.