On 8/12/19 4:35 PM, Trevor.Conn@... wrote:
See italicized responses to Tony's email inline
Technical Staff Engineer
On 8/12/19 12:20 PM,
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
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
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
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
I propose we add
an environment var like
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 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.
Technical Staff Engineer