...

We are exploring two options for implementing such an interface, and we will discuss them in detail below.

Option 1:  Process security config during pillar container launchSeparate REST API, completely handled by Vault Manager

Option 2:  Process security config inside ZedAgent serviceSame API that carries other config, handled by zedAgent

Option 3:  Same API, handled by Vault Manager at boot time, and ZedAgent at runtime

Option 1: 

...

Separate REST API, completely handled by Vault Manager

Current Workflow in Provisioning EVE

...

This module in EVE, will be responsible for periodic device policy fetch from controller and enforce them on the device.  More details, are specified in [Ref.1].

Option 2: 

...

Same API that carries other config, handled by zedAgent

In this approach, security policies are pushed along with other config, and parsed by zedagent. But zedagent will prioritise handling of security config over the rest of the config.  Any file system interaction to setup/unlock the vault directory will have to be done according to the security config received, and then signal others that vault directory is now ready for use.  Other services can listen to this to perform any task they need to do on top of the vault directory.  Zedagent would interact with Vault Manager service for implementing file system encryption requirements. 

Option 3:  Same API, handled by Vault Manager at boot time, and ZedAgent at runtime

It is a mix of Option 1 and Option 2. It uses the same REST API that is used for pulling the device configuration. But Vault Manager will extract security config parts during pillar launch, to set up any filesystem encryption etc.  Once ZedAgent takes over, any further change in security config can be driven from zedAgent, by passing the configuration to Vault Manager through pubsub mechanism.

Break-up of the proposed security config (Applicable to

...

all the Approaches)

The policies are grouped into two major categories

...