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
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
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
Technical Staff Engineer