Skip to content

Security Considerations

This guide will cover security considerations for the AiCSD Project.

  1. This Project is an Open Source Sample intended to be used as a potential use case/functionality, "Art of the Possible”.
  2. This is not intended to be a full solution; hence it deviates from the Intel SDLe Policy for Open Source Release of not meeting Production SDL. However, it is sufficient to be released as an Open Source Sample.
  3. This Open Source Sample is not intended to be used in a Production environment. Changes are required to improve security for a production environment.

Security Implementation

This system is secured using the secure version of EdgeX Foundry. The EdgeX message bus is a secure Redis implementation. In a single system setup, all services in the solution are configured as Add-on application services to Secure EdgeX. In a two system setup, the Gateway services are configured as add-on services, while the OEM services need to connect using SSH Tunneling. This implementation is an extension of the EdgeX example for Remote Device Services in Secure Mode.

Additional steps to secure this Open Source Sample

The following list covers the additional features that need to be implemented to secure this open Source Sample:

OEM

  1. Need to add an API gateway such as Kong to control access to OEM endpoints.
  2. Communications inside the OEM are not internally secure. Nothing prevents services from being called on localhost.

Gateway

  1. User Authentication needs to be implemented for the Web UI running on the Gateway.
  2. Communications inside the gateway are not internally secure. Kong provides an API Gateway for external callers, but does not prevent services from being called on localhost.
  3. The external MQTT broker for exporting results is not secure and should be replaced with a secure message broker.
  4. The Web UI operates over http not https meaning that network communications are not encrypted.

Other

  1. For data privacy guidelines, do not insert any personal identification content in job attributes like filename etc.
  2. Key pairs generated by ssh-keygen (4096-bit RSA keys) should be password protected.
  3. Key pairs should be unique to each set of systems and rotated at least every 3 years.
  4. There is currently no access control system in this project.
  5. Files should be encrypted and transferred over https instead of http.
  6. Implement TLS for Kong, Vault, and Redis (pub/sub) or a zero trust networking solution like OpenZiti in order to prevent the use of the secure port forwarding for communication between the OEM and Gateway.

AiCSD Crash Mitigation

  1. The Monitoring, Log Analytics and Portainer features help monitor any failed/crashed docker containers.
  2. If either microservices fail, then end to end ML pipeline execution will fail.
  3. Hence the specific failed docker service can be restarted via Portainer. If the issue still persists, then all the docker containers can be restarted.

  4. If the issue is still not resolved, run the following commands to remove all docker containers, images, volume, and image files. Archived input and output files are available in the archive folder on the Gateway. If required, files can be copied and then deleted from the OEM and Gateway file systems.

     make down clean-volumes clean-images clean-files

  5. Users can refer to Troubleshooting Services and Troubleshooting Tools sections to debug and resolve any issues encountered.