Application Management Requirements

Open

Utilities want to be able to use a single management system. With this in mind, interoperable requirements are insufficient. An interoperable implementation is required. GEISA will specify what an agent running on the GEISA environment must do, as well as the API between the agent and the management system. GEISA may provide an agent implementation.

Application management requirements:

• Start / Stop Application

  • Agent must support starting and stopping applications based on commands from the management system

  • Agent should support restart and watchdog functions

  • Management system should be able to configure restart and watchdog behavior

• Deploy Application

  • Transfer the image from the management system to the device

  • Validate the image cryptographically

  • Pre-install actions

  • Install the image on the device (e.g. unpack it, copy files, etc.)

  • Post-install actions

• Update Application

  • Includes deployment of replacement image or patching of existing installation

  • Automatically managed stop / restart process

• Reset Application

  • Purges user-specific data and returns application to original time-of-install state (useful for move-ins / move-outs or other events where older data may no longer be valid or acceptable.)

  • Note: GEISA may require all application and user data to be placed on a dedicated separate file-system where the entire file-system can be purged to reset a device to an untouched state.

  • There was on-going discussion about the idea that applications would have two general types of data. Customer-specific data and general app-data. The system should allow purging of customer specific data without purging the general app data.

• Decommission Application

  • Purges user-specific data and remove the application from the device

Application Isolation Requirements

The team discussed what the requirements were for application isolation. We started by reviewing what we felt was necessary to address the operational needs of utilities deploying apps at the edge.

Open

Requirements include:

• Applications should run in independent processes

• Application access permissions should be deny by default

• Applications cannot impact the performance or stability of the O/S

• Applications cannot impact the performance or stability of other applications

• System can control app-to-app communications.

• App-to-app communications will be denied by default

• Apps cannot access other apps memory or other resources

• Apps should not know about other apps unless explicitly informed

• Access to the local file-system will be isolated / restricted

• An authenticated application manifest issued by the owner of the system will control access to resources including:

• Isolation Mechanism must be reasonably efficient

• Apps must run with least privilege.

• System must be able to inspect and control application packet flows

After discussing the requirements we discussed how we could achieve them. Three options were considered:

• Native applications running under Linux

• Containerized applications running under Linux

• Virtual machines

Virtual machines were considered too heavy for our target environment and rejected as a requirement. This left native applications and containers. The concern with containers is that they can also be too heavy. Some participants have had issues with containers and switched to native applications in response. The concern with native applications is that they do not provide the level of isolation containers do, particularly when the network requirements (see above) are considered. Several rounds of group discussion occurred. It was noted that containers are built on cgroups and namespaces within the Linux kernel, and can be implemented a variety of ways. Containers need not take the rather inefficient approach that Docker does.

The team decided to move forward with containers, tasking a sub-team to investigate the best / most efficient approach for implementing containers in a constrained environment. The team also agreed that there may be a need to support native applications as well, especially if advanced hardware features cannot be accessed from a container. This support would be a future (not 1.0) feature, unless a specific gap is found. Finally, it was noted that an implementer could choose to run a container in a virtual machine. Provided that the implementer supports the specified controls, interfaces, and requirements, this would be a compliant implementation.

OS Specification

Open