Re: [Edgex-tsc-core] Security Enablement
Well stated and explained Ian. I agree with you and thanks for writing it up.
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
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.