Date   
Re: Global config settings in Consul using Registry API

James.White2@...
 

+1 – nice work Lenny and good feedback Trevor.  Thanks for the questions Malini.

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Goodell, Leonard
Sent: Thursday, August 15, 2019 5:19 PM
To: Bhandaru, Malini (VMware); Conn, Trevor; EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

[EXTERNAL EMAIL]

See below

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Malini Bhandaru via Lists.Edgexfoundry.Org
Sent: Thursday, August 15, 2019 2:43 PM
To: Goodell, Leonard <leonard.goodell@...>; Conn, Trevor (EMC) <Trevor_Conn@...>; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

Different registry clients helps by encapsulating the stems and respective service keys. Host, port, and type for the registry itself common to all.

So gets and puts do not have to expose via API argument string the construction of the key path – NICE

No need for special parsing like in my suggestion.

Can service-A  “get” service-B keys? Assuming no “put”.

Yes, if configurated appropriately.

 

 

From: "Goodell, Leonard" <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 2:36 PM
To: "Conn, Trevor (EMC)" <Trevor_Conn@...>, "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>, Malini Bhandaru <mbhandaru@...>
Subject: RE: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

Trevor,

  I like it! This works nicely for config-seed to put the values. Are you thinking the services would create a second Registry client configured to get the global values?

 

If we had a GlobalConfig struct holding multiple global configuration settings, the service could get them with one call to GetConfiguration on the global client. If think it would look like:

type GlobalConfig struct {

   Security SecurityInfo

   ….

}

 

Just thinking of the possibilities…. 😉

 

-Lenny

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Trevor.Conn@...
Sent: Thursday, August 15, 2019 1:21 PM
To: Goodell, Leonard <leonard.goodell@...>; EdgeX-TSC-Core@...; mbhandaru@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

To recap for folks, we initialize the RegistryClient by passing it a configuration struct at runtime. That operation looks like this:

 

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       internal.ConfigRegistryStem,
  
ServiceKey: clients.ServiceKeyPrefix + serviceName,
}
Registry
, err = registry.NewRegistryClient(registryConfig)

To set global configurations as we discussed this morning, I propose we reorganize our constants a bit. Refer here for the relevant edgex-go constants.

 

1.) Re-assign value of current ConfigRegistryStem constant

 

ConfigRegistryStem = "edgex/core"

 

2. ) Define three new constants

 

ConfigMajorVersion = "1.0"

ConfigGlobalStem = "edgex/global"

SecretStoreKey = "security-secret-store"

 

3.) To write to a global location, all we'd have to do is instantiate a RegistryClient like so and then use it. Notice that the ServiceKey is not set.

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       strings.Join([]string{internal.ConfigGlobalStem, internal.ConfigMajorVersion},"/")
}
Registry
, err = registry.NewRegistryClient(registryConfig)

err := Registry.PutConfigurationValue(
internal.SecretStoreKey, true)

This would create an entry in Consul at /edgex/global/1.0/security-secret-store.

 

If we wanted to group all of the security-related options within a "Security" section, as Lenny describes, then we would define another constant and populate the ServiceKey on the RegistryConfig with that value. Such usage would give us the following path.

/edgex/global/1.0/security/security-secret-store

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> on behalf of Malini Bhandaru via Lists.Edgexfoundry.Org <mbhandaru=vmware.com@...>
Sent: Thursday, August 15, 2019 2:01 PM
To: leonard.goodell@...; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

[EXTERNAL EMAIL]

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

 

Re: Global config settings in Consul using Registry API

Goodell, Leonard
 

See below

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Malini Bhandaru via Lists.Edgexfoundry.Org
Sent: Thursday, August 15, 2019 2:43 PM
To: Goodell, Leonard <leonard.goodell@...>; Conn, Trevor (EMC) <Trevor_Conn@...>; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

Different registry clients helps by encapsulating the stems and respective service keys. Host, port, and type for the registry itself common to all.

So gets and puts do not have to expose via API argument string the construction of the key path – NICE

No need for special parsing like in my suggestion.

Can service-A  “get” service-B keys? Assuming no “put”.

Yes, if configurated appropriately.

 

 

From: "Goodell, Leonard" <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 2:36 PM
To: "Conn, Trevor (EMC)" <Trevor_Conn@...>, "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>, Malini Bhandaru <mbhandaru@...>
Subject: RE: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

Trevor,

  I like it! This works nicely for config-seed to put the values. Are you thinking the services would create a second Registry client configured to get the global values?

 

If we had a GlobalConfig struct holding multiple global configuration settings, the service could get them with one call to GetConfiguration on the global client. If think it would look like:

type GlobalConfig struct {

   Security SecurityInfo

   ….

}

 

Just thinking of the possibilities…. 😉

 

-Lenny

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Trevor.Conn@...
Sent: Thursday, August 15, 2019 1:21 PM
To: Goodell, Leonard <leonard.goodell@...>; EdgeX-TSC-Core@...; mbhandaru@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

To recap for folks, we initialize the RegistryClient by passing it a configuration struct at runtime. That operation looks like this:

 

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       internal.ConfigRegistryStem,
  
ServiceKey: clients.ServiceKeyPrefix + serviceName,
}
Registry
, err = registry.NewRegistryClient(registryConfig)

To set global configurations as we discussed this morning, I propose we reorganize our constants a bit. Refer here for the relevant edgex-go constants.

 

1.) Re-assign value of current ConfigRegistryStem constant

 

ConfigRegistryStem = "edgex/core"

 

2. ) Define three new constants

 

ConfigMajorVersion = "1.0"

ConfigGlobalStem = "edgex/global"

SecretStoreKey = "security-secret-store"

 

3.) To write to a global location, all we'd have to do is instantiate a RegistryClient like so and then use it. Notice that the ServiceKey is not set.

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       strings.Join([]string{internal.ConfigGlobalStem, internal.ConfigMajorVersion},"/")
}
Registry
, err = registry.NewRegistryClient(registryConfig)

err := Registry.PutConfigurationValue(
internal.SecretStoreKey, true)

This would create an entry in Consul at /edgex/global/1.0/security-secret-store.

 

If we wanted to group all of the security-related options within a "Security" section, as Lenny describes, then we would define another constant and populate the ServiceKey on the RegistryConfig with that value. Such usage would give us the following path.

/edgex/global/1.0/security/security-secret-store

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> on behalf of Malini Bhandaru via Lists.Edgexfoundry.Org <mbhandaru=vmware.com@...>
Sent: Thursday, August 15, 2019 2:01 PM
To: leonard.goodell@...; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

[EXTERNAL EMAIL]

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

 

Re: Global config settings in Consul using Registry API

Malini Bhandaru
 

Different registry clients helps by encapsulating the stems and respective service keys. Host, port, and type for the registry itself common to all.

So gets and puts do not have to expose via API argument string the construction of the key path – NICE

No need for special parsing like in my suggestion.

Can service-A  “get” service-B keys? Assuming no “put”.

 

 

From: "Goodell, Leonard" <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 2:36 PM
To: "Conn, Trevor (EMC)" <Trevor_Conn@...>, "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>, Malini Bhandaru <mbhandaru@...>
Subject: RE: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

Trevor,

  I like it! This works nicely for config-seed to put the values. Are you thinking the services would create a second Registry client configured to get the global values?

 

If we had a GlobalConfig struct holding multiple global configuration settings, the service could get them with one call to GetConfiguration on the global client. If think it would look like:

type GlobalConfig struct {

   Security SecurityInfo

   ….

}

 

Just thinking of the possibilities…. 😉

 

-Lenny

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Trevor.Conn@...
Sent: Thursday, August 15, 2019 1:21 PM
To: Goodell, Leonard <leonard.goodell@...>; EdgeX-TSC-Core@...; mbhandaru@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

To recap for folks, we initialize the RegistryClient by passing it a configuration struct at runtime. That operation looks like this:

 

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       internal.ConfigRegistryStem,
  
ServiceKey: clients.ServiceKeyPrefix + serviceName,
}
Registry
, err = registry.NewRegistryClient(registryConfig)

To set global configurations as we discussed this morning, I propose we reorganize our constants a bit. Refer here for the relevant edgex-go constants.

 

1.) Re-assign value of current ConfigRegistryStem constant

 

ConfigRegistryStem = "edgex/core"

 

2. ) Define three new constants

 

ConfigMajorVersion = "1.0"

ConfigGlobalStem = "edgex/global"

SecretStoreKey = "security-secret-store"

 

3.) To write to a global location, all we'd have to do is instantiate a RegistryClient like so and then use it. Notice that the ServiceKey is not set.

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       strings.Join([]string{internal.ConfigGlobalStem, internal.ConfigMajorVersion},"/")
}
Registry
, err = registry.NewRegistryClient(registryConfig)

err := Registry.PutConfigurationValue(
internal.SecretStoreKey, true)

This would create an entry in Consul at /edgex/global/1.0/security-secret-store.

 

If we wanted to group all of the security-related options within a "Security" section, as Lenny describes, then we would define another constant and populate the ServiceKey on the RegistryConfig with that value. Such usage would give us the following path.

/edgex/global/1.0/security/security-secret-store

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> on behalf of Malini Bhandaru via Lists.Edgexfoundry.Org <mbhandaru=vmware.com@...>
Sent: Thursday, August 15, 2019 2:01 PM
To: leonard.goodell@...; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

[EXTERNAL EMAIL]

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

Re: Global config settings in Consul using Registry API

Goodell, Leonard
 

Hi Malini,

  Yes, I was planning on keeping the API unchanged to not break clients. I think this is no longer relevant with Trevor’s approach.

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Malini Bhandaru via Lists.Edgexfoundry.Org
Sent: Thursday, August 15, 2019 12:02 PM
To: Goodell, Leonard <leonard.goodell@...>; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

Re: Global config settings in Consul using Registry API

Goodell, Leonard
 

Trevor,

  I like it! This works nicely for config-seed to put the values. Are you thinking the services would create a second Registry client configured to get the global values?

 

If we had a GlobalConfig struct holding multiple global configuration settings, the service could get them with one call to GetConfiguration on the global client. If think it would look like:

type GlobalConfig struct {

   Security SecurityInfo

   ….

}

 

Just thinking of the possibilities…. 😉

 

-Lenny

 

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> On Behalf Of Trevor.Conn@...
Sent: Thursday, August 15, 2019 1:21 PM
To: Goodell, Leonard <leonard.goodell@...>; EdgeX-TSC-Core@...; mbhandaru@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

To recap for folks, we initialize the RegistryClient by passing it a configuration struct at runtime. That operation looks like this:

 

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       internal.ConfigRegistryStem,
  
ServiceKey: clients.ServiceKeyPrefix + serviceName,
}
Registry
, err = registry.NewRegistryClient(registryConfig)

To set global configurations as we discussed this morning, I propose we reorganize our constants a bit. Refer here for the relevant edgex-go constants.

 

1.) Re-assign value of current ConfigRegistryStem constant

 

ConfigRegistryStem = "edgex/core"

 

2. ) Define three new constants

 

ConfigMajorVersion = "1.0"

ConfigGlobalStem = "edgex/global"

SecretStoreKey = "security-secret-store"

 

3.) To write to a global location, all we'd have to do is instantiate a RegistryClient like so and then use it. Notice that the ServiceKey is not set.

registryConfig := types.Config{
   Host:       Configuration.Registry.Host
,
  
Port:       Configuration.Registry.Port,
  
Type:       Configuration.Registry.Type,
  
Stem:       strings.Join([]string{internal.ConfigGlobalStem, internal.ConfigMajorVersion},"/")
}
Registry
, err = registry.NewRegistryClient(registryConfig)

err := Registry.PutConfigurationValue(
internal.SecretStoreKey, true)

This would create an entry in Consul at /edgex/global/1.0/security-secret-store.

 

If we wanted to group all of the security-related options within a "Security" section, as Lenny describes, then we would define another constant and populate the ServiceKey on the RegistryConfig with that value. Such usage would give us the following path.

/edgex/global/1.0/security/security-secret-store

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA


From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> on behalf of Malini Bhandaru via Lists.Edgexfoundry.Org <mbhandaru=vmware.com@...>
Sent: Thursday, August 15, 2019 2:01 PM
To: leonard.goodell@...; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

[EXTERNAL EMAIL]

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

Re: Global config settings in Consul using Registry API

Trevor.Conn@...
 

To recap for folks, we initialize the RegistryClient by passing it a configuration struct at runtime. That operation looks like this:


registryConfig := types.Config{
Host: Configuration.Registry.Host,
Port: Configuration.Registry.Port,
Type: Configuration.Registry.Type,
Stem: internal.ConfigRegistryStem,
ServiceKey: clients.ServiceKeyPrefix + serviceName,
}
Registry, err = registry.NewRegistryClient(registryConfig)

To set global configurations as we discussed this morning, I propose we reorganize our constants a bit. Refer here for the relevant edgex-go constants.


1.) Re-assign value of current ConfigRegistryStem constant


ConfigRegistryStem = "edgex/core"


2. ) Define three new constants


ConfigMajorVersion = "1.0"

ConfigGlobalStem = "edgex/global"

SecretStoreKey = "security-secret-store"


3.) To write to a global location, all we'd have to do is instantiate a RegistryClient like so and then use it. Notice that the ServiceKey is not set.

registryConfig := types.Config{
Host: Configuration.Registry.Host,
Port: Configuration.Registry.Port,
Type: Configuration.Registry.Type,
Stem: strings.Join([]string{internal.ConfigGlobalStem, internal.ConfigMajorVersion},"/")
}
Registry, err = registry.NewRegistryClient(registryConfig)

err := Registry.PutConfigurationValue(internal.SecretStoreKey, true)

This would create an entry in Consul at /edgex/global/1.0/security-secret-store.


If we wanted to group all of the security-related options within a "Security" section, as Lenny describes, then we would define another constant and populate the ServiceKey on the RegistryConfig with that value. Such usage would give us the following path.

/edgex/global/1.0/security/security-secret-store


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

From: EdgeX-TSC-Core@... <EdgeX-TSC-Core@...> on behalf of Malini Bhandaru via Lists.Edgexfoundry.Org <mbhandaru=vmware.com@...>
Sent: Thursday, August 15, 2019 2:01 PM
To: leonard.goodell@...; EdgeX-TSC-Core@...
Cc: EdgeX-TSC-Core@...
Subject: Re: [Edgex-tsc-core] Global config settings in Consul using Registry API
 

[EXTERNAL EMAIL]

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

Re: Global config settings in Consul using Registry API

Malini Bhandaru
 

Lenny I am guessing you want to keep the API unchanged, as in taking one string for  get, and two for put.

It requires clients to construct the full  path edgex/code/<version>/<service>

Do you anticipate a service 2.0 wanting a version 1.0 key --- room for errors

Would it make sense to just have

<new-key-arg> ::= [[“global” | <service-name>]:]<key>

The expense is then mainly at the key parsing stage

 

This way if the string starts with global … check there

If there is a service name implies use it, client is seeking something out of the current service context

No versions specified .. thus no error, using the service version number

This might even be good enough to not have to revisit in G time frame.

 

Malini

 

From: <EdgeX-TSC-Core@...> on behalf of "Goodell, Leonard via Lists.Edgexfoundry.Org" <leonard.goodell=intel.com@...>
Reply-To: "leonard.goodell@..." <leonard.goodell@...>
Date: Thursday, August 15, 2019 at 11:37 AM
To: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Cc: "EdgeX-TSC-Core@..." <EdgeX-TSC-Core@...>
Subject: [Edgex-tsc-core] Global config settings in Consul using Registry API

 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

Global config settings in Consul using Registry API

Goodell, Leonard
 

All,

  After today's Core WG meeting I investigated how we might have Global configuration settings using the Registry API. The current API has PutConfigurationValue & GetConfigurationValue. The implementation of these for Consul prepends the service’s base path, i.e. edgex/core/1.0/edgex-core-data/, to the key passed in from the TOML file like Writable.LoggignLevel. This resulting in a path in Consul like edgex/core/1.0/edgex-core-data/Writable/LogLevel

 

I think we could tweak the Consul implementation for these Put/Get APIs to override the base path if the key starts with a `/`.  Global keys could then look like /edgex/global/1.0/Security/use-secret-store and /edgex/global/1.0/Security/secret-store-token-path

 

I think this would be enough for Fuji. When we refactor the Registry API for Geneva to split out Config and Registry we could look at adding better support for a Global section which would eliminate extra calls to these Put/Get APIs.

 

thoughts?

 

-Lenny

 

Upcoming Event: EdgeX Core WG Meeting (Weekly) - Thu, 08/15/2019 8:00am-9:00am, Please RSVP #cal-reminder

EdgeX-TSC-Core@lists.edgexfoundry.org Calendar <EdgeX-TSC-Core@...>
 

Reminder: EdgeX Core WG Meeting (Weekly)

When: Thursday, 15 August 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/201883906

An RSVP is requested. Click here to RSVP

Organizer: EdgeX-TSC-Core@...

Description: EdgeX Core WG Meeting. Meeting content posted to Core WG Wiki.
Meeting Lead: Trevor Conn, Core WG Chair, trevor_conn@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/201883906

Or iPhone one-tap (US Toll): +16468769923,,201883906# or +16699006833,,201883906#

Or Telephone:
    Dial: +1 646 876 9923 (US Toll) or +1 669 900 6833 (US Toll)
    +1 877 369 0926 (US Toll Free)
    +1 877 853 5247 (US Toll Free)
    Meeting ID: 201 883 906
    International numbers available: https://zoom.us/zoomconference?m=Qqq7sz4L88ze6B1M1tTIMQkO-eZL20cy

Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement

Trevor.Conn@...
 

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

[EXTERNAL EMAIL]

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

 

 

 

Thanks

Doug Gardner

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

 

[External]

 

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. 

 

Thanks,

Ian

 

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

Inline under Trevor’s comment

 

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

 

[EXTERNAL EMAIL]

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”

 

Regards,
/tony

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    

Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement

Gardner, Doug <Doug.Gardner@...>
 

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

 

 

 

Thanks

Doug Gardner

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

 

[External]

 

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. 

 

Thanks,

Ian

 

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

Inline under Trevor’s comment

 

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

 

[EXTERNAL EMAIL]

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”

 

Regards,
/tony

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    

Re: Security Enablement

Ian Johnson
 

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. 

Thanks,
Ian


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

Inline under Trevor’s comment

 

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

 

[EXTERNAL EMAIL]

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”

 

Regards,
/tony

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    

Re: Security Enablement

Malini Bhandaru
 

Inline under Trevor’s comment

 

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

 

[EXTERNAL EMAIL]

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”

 

Regards,
/tony

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    

Re: Security Enablement

espy
 

On 8/12/19 4:35 PM, Trevor.Conn@... wrote:

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

[EXTERNAL EMAIL]

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.

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


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


/tony


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.


Regards,
/tony


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

Re: 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

Re: Security Enablement

Trevor.Conn@...
 

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

[EXTERNAL EMAIL]

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.


Regards,
/tony


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

Re: Security Enablement

espy
 

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    

Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement

Malini Bhandaru
 

Trevor did you mean “EDGEX_SECURITY=OFF” as opposed to “EDGEX_SECURITY=ON

Because Fuji has it on by default, the environment variable defaults to ON and to be backward compatible, need to turn it off.

+1 for environment variable.

 

 

From: <EdgeX-TSC-Security@...> on behalf of "Jim Wang Intel via Lists.Edgexfoundry.Org" <yutsung.jim.wang=intel.com@...>
Reply-To: "yutsung.jim.wang@..." <yutsung.jim.wang@...>
Date: Monday, August 12, 2019 at 10:13 AM
To: "Frusetta, Beau" <beau.frusetta@...>, "Conn, Trevor (EMC)" <Trevor_Conn@...>, "edgex-tsc-core@..." <edgex-tsc-core@...>, "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Cc: "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Subject: Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement

 

EDGEX_SECURITY=ON

Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement

Goodell, Leonard
 

+1 for environment variable

 

From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of Jim Wang Intel
Sent: Monday, August 12, 2019 10:13 AM
To: Frusetta, Beau <beau.frusetta@...>; Trevor.Conn@...; edgex-tsc-core@...; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] [Edgex-tsc-core] Security Enablement

 

+1 for using environment variable. -Jim

 

From: EdgeX-TSC-Core@... [mailto:EdgeX-TSC-Core@...] On Behalf Of Beau Frusetta
Sent: Monday, August 12, 2019 9:43 AM
To: Trevor.Conn@...; edgex-tsc-core@...; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-core] Security Enablement

 

I like the use of an environment variable – especially given consideration for backwards compatibility and different methods of distributing/running EdgeX (native, containers, snaps, future…)

 

Beau Frusetta

IOTG/RBHE, Software Engineering Manager

 

"Beware the quiet man. For while others speak, he watches. And while others act, he plans. And when they finally rest...he strikes." - Anonymous

 

From: EdgeX-TSC-Core@... [mailto:EdgeX-TSC-Core@...] On Behalf Of Trevor.Conn@...
Sent: Monday, August 12, 2019 09:21
To: edgex-tsc-core@...; EdgeX-TSC-Security@...
Subject: [Edgex-tsc-core] Security Enablement

 

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

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    


--
Best Regards,
  Jim Wang
  Retail Solutions Division / IOTG
  Intel Corporation

Re: Security Enablement

Jim Wang Intel
 

+1 for using environment variable. -Jim

 

From: EdgeX-TSC-Core@... [mailto:EdgeX-TSC-Core@...] On Behalf Of Beau Frusetta
Sent: Monday, August 12, 2019 9:43 AM
To: Trevor.Conn@...; edgex-tsc-core@...; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-core] Security Enablement

 

I like the use of an environment variable – especially given consideration for backwards compatibility and different methods of distributing/running EdgeX (native, containers, snaps, future…)

 

Beau Frusetta

IOTG/RBHE, Software Engineering Manager

 

"Beware the quiet man. For while others speak, he watches. And while others act, he plans. And when they finally rest...he strikes." - Anonymous

 

From: EdgeX-TSC-Core@... [mailto:EdgeX-TSC-Core@...] On Behalf Of Trevor.Conn@...
Sent: Monday, August 12, 2019 09:21
To: edgex-tsc-core@...; EdgeX-TSC-Security@...
Subject: [Edgex-tsc-core] Security Enablement

 

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

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA
    


--
Best Regards,
  Jim Wang
  Retail Solutions Division / IOTG
  Intel Corporation