Security

The primary security objective of the EII is to prevent time series and video data generated by the ingestion or analytics components from being accessed by unauthorized entities acting within the system or accessing it via the external network interfaces.

Security is enabled in a two-stage process involving provisioning and execution on an edge compute node. The root user is considered a trusted entity; therefore, compromising the root password or giving Linux* sudoer permission to an untrusted user on the edge compute node will compromise security.

Provisioning

Provisioning must be done before deploying EII on any node. Provisioning will start EII Config Manager Agent as a container and load it with the configuration required to run EII for single or multi-node cluster setup.

The provisioning step of EII include done by Config Manager Agent microservice includes:

1. Stores the configurations of other microservices to the distributed key-value store (etcd) for configuration management

2. Creates required provisioning folders with the right permissions needed for the data persistence of microservices

3. Additionally in PROD mode, generates

   1. Keys/certificates required for interaction with etcd and shared with each microservice through specific volume mounts

   2. Message Bus keys for microservices communication stored in etcd

Generating Keys and Certificates

EII’s Config Manager Agent microservice creates private keys and cert pair for all EII containers. It uses OpenSSL commands to create the X.509 certs and private keys with names expected by the sample docker-compose.yml provided with the release. The user can opt to generate these certs using any tool and update the docker-compose.yml with the corresponding names for the final deployment.

The following certificates are generated by the Config Manager Agent microservice:

1. X.509 CA certificate, which is self-signed. This step can be omitted if the admin provides their own pre-generated CA certificate to the tool.

2. Root user private key and certificates

3. Private key and certificate for all the applications (provided in the configuration).

4. Peer certificate to be generated for each node in the cluster.

The Config Manager Agent microservice will generate these keys and certificates and will keep them in a “Certificates/” directory with unique filenames for each certificate. This directory will be referred by the docker-compose.yml file for mounting these as secrets to the container, similar setup is applicable for the k8s deployment.

Start Up and Run Time

During Edge Compute Node reboot, the secrets stored in the distributed key-value store (*etcd) of EII Config Manager Agent microservice need to be accessible to all of the EII infrastructure containers. EII Config Manager Agent microservice plays a crucial role in providing the secrets to other containers.

Accessing Secrets

1. Keys/certificates required for interaction with etcd and shared with each microservice through specific volume mounts

2. Call the ConfigMgr library (EII ConfigMgr client) for reading the application configurations (using the EII user EII Config Manager Agent’s pub/pri key pair).

3. Read the message bus topics and message bus configurations for Pub / Sub and Request Response along with the ZMQ private keys.

4. For a publisher, the application needs the public keys of all subscribers. From the list of subscribers mentioned in the application EII Config Manager Agent configuration, the application needs to query the Config Manager Agent and gets the public keys of all subscribers from EII Config Manager Agent. The application will pass this configuration to the EII message bus.

5. For a subscriber, the Config Manager Agent is used for getting the public key of the publisher and connecting to it.

Certificate Revocation

Individual users can be deleted from the EII Config Manager Agent to revoke their certificates. In case of ZeroMQ* certificate revocation, the client’s public key can be removed from the allowed_clients option of the publisher.