The current architecture has a genaral problem, i didn't considered the permission topic. To modify cpu-speed and other hardware-related tasks, root permissions are required and priviledged docker-container. From security perspective this is a problem. Ironically this problem was already solved in the past, where i had the microservice architecture and the hardware related functions were encapsulated within a separate component. The hardware function have to be outsourced in a separate component with its own container again, but in a more minimal version than in the past.
Acceptance Criteria
hardware related functions are moved into a new component
the new component interacts with hanami over a UDP-socket
the old hanami_network lib from the archive was re-activated for the connection
the new component has now own config, but only reads necessary config-data over the UDP-socket
the new component has NO Rest-API or any other connection to the outside world
the container of the new component has root-permissions to be able to perform the required tasks
Feature
Description
The current architecture has a genaral problem, i didn't considered the permission topic. To modify cpu-speed and other hardware-related tasks, root permissions are required and priviledged docker-container. From security perspective this is a problem. Ironically this problem was already solved in the past, where i had the microservice architecture and the hardware related functions were encapsulated within a separate component. The hardware function have to be outsourced in a separate component with its own container again, but in a more minimal version than in the past.
Acceptance Criteria
Blocked by
How to test