Secure Installation

General Description

The Secure Installation component provides the means to securely install applications on the ZDMP platform. This component acts on behalf of the user when they request an installation of a zApp through the ZDMP Marketplace (the trustworthy Marketplace developed for hosting zApps). It allows a secure downloading process from the Marketplace, and the policies the zApp is requesting (eg access to databases). A given zApp is not directly installed in the ZDMP platform unless it passes the review of the IT administrator. By leveraging the Security Command Centre UI, the IT Administrator can then accept or reject the policies a given zApp is requesting. Once approved, the IT administrator can then install the zApp (deploying it into the Application Runtime). Additionally, through the Security Command Centre UI the IT administrator can install a Certificate Authority (CA), as well as issue a client certificate for any of the installed CAs.

Resource Location
Source Code Link
Latest Release (v1.0.0) Download
X Open API Spec Link
Video Link
Further Guidance Link
Related Datasets None
Additional links None
Generation of this content 6 May 2021

The date of generation of this component content is: 6 May 2021

Screenshots

The following images are illustrative screen shots of the component

Figure 40: Secure installation overview

Component Author(s)

Company Name ZDMP Acronym Website Logo
IKERLAN IKER www.ikerlan.es

Commercial Information

Resource Location
IPR Link Link
Price [For determination at end of project]
Licence [For determination at end of project]
Privacy Policy [For determination at end of project]
Volume license [For determination at end of project]

Architecture Diagram

The following diagram shows the position of this component in the ZDMP architecture

Figure 41: Position of Component in ZDMP Architecture

Benefits

  • Configure and revise zApp permissions before they are installed to the ZDMP platform, so that they only have access to those components that are essential, enabling the least privilege policy and avoiding unwanted access

  • Deploy zApps to the ZDMP platform semi-automatically, to save time and effort

Features

The features to achieve the functionality of this component are itemised below and explained thereafter:

  • Security Command Centre

  • Installation Broker

Security Command Centre

The Security Command Centre is the main subcomponent of the security component architecture. It provides the following features:

  • Security policies creation: Security policies can be created/reviewed in this GUI. This process is conducted each time that a new zApp is approved for installation so that its access permissions are well established

  • User policies creation: Security administrators can register and edit roles for users and zApps that permit access to ZDMP resources (eg to the storage component) in this GUI

  • Security certificates control: In this function, the installation of new root certificates and the revocation of user certificates can be done. These actions are critical to keep the ZDMP platform secure and can be triggered manually by a security administrator

Installation Broker

The Installation Broker Service is the module that supports the Security Command Centre in the downloading and installation of a new zApp. It provides the following features:

  • ZApps installation: Users request the installation of the zApp package through the Security Command Centre UI. Then, the user must accept all the policies specified by the zApp request and the installation to the application-runtime environment is processed

  • ZApps verification: The Installation Broker Service conducts the security checks, such the manifest signature verification, on the downloaded zApp package

  • ZApp permissions creation: When the security checks are successful, the Installation Broker Service requests the Security Command Centre to create relationships between the user, the zApp and the required permissions

  • Multitenancy: The component at hand is able to store and manage data from different organizations (tenants)

System Requirements

Minimal requirements needed:

  • Computer with Docker Engine installed (tested in v19.03.8, on Windows)

  • The average resources needed to run this component are: 2 CPUs, 2GB memory and 10GB free space on disk

Installation

The installation of this component is performed through Docker commands to run Docker images. The Secure Installation component can be installed via Docker-compose:

  1. Download the latest source code from ZDMP’s GitLab repository Download

  2. Unzip the folder in the desired workspace/

  3. Through the command line, go to the orchestration folder and run docker-compose command as follows:

zdmpadmin@localhost: cd t5.2-secure-installation/orchestration
zdmpadmin@localhost:~$ docker-compose up -d

This deploys three Docker containers in the host machine where the docker-compose up -d command was launched.

How to use

The insights on how to use this component are itemised below and explained thereafter:

  • Access to the Security Command Centre UI

  • Retrieving zApp Installation Requests

  • Reviewing zApp Policies

  • zApp Manifest

Access to the Security Command Centre UI

Once subsystems are launched the Security Command Centre UI can be accessed at http://localhost:3000 The browser renders the following login page:

The Dash Button component manages the authentication process. Once completed, the user gets redirected back to the Security Command Centre UI.

Note: *The logged user should have the ZDMP_IT_Security_Commander role, otherwise it is not allowed to interact with the system.*

Figure 42: Security command centre UI welcome page

Retrieving zApp installation requests

Once logged in, the zApp installation requests list can be viewed by clicking on the left menu “zApp Install Requests”.

Here the IT administrator can view the zApps already installed (status is INSTALLED) and can also inspect which have been requested to be installed but are pending to revise (status is DOWNLOADED).

For troubleshooting purposes there are other possible statuses a zApp installation request may have:

  • MANIFEST_FETCHED: When the specified zApp repository contains a manifest file (Otherwise the ERROR: INVALID_GITLAB_TOKEN_SERVER_PROJECT status is shown)

  • MANIFEST_DECODED: When the manifest file Is successfully decoded

  • DOWNLOADED: The manifest has been fully parsed and it is ready to be installed (pending policies approvals). If the manifest cannot be parsed, the zApp status changes to ERROR: MALFORMED_MANIFEST

  • CREATING_RESOURCES: This status is displayed to acknowledge the users deploy to the app runtime request. If a Keycloak client already exists, the status changes to ERROR: CONFLICT. For other errors such as connectivity problems etc, the status is ERROR: UNKNOWN

Figure 43: Security command centre zApp installation request list

Reviewing zApp policies

The IT admin can review the list of policies that a given zApp is requesting either by clicking on “Linked policies” from the zApp Install Requests table or by accessing the left menu item “zApp Policies”. Here, the IT admin can go one by one reviewing the requested policy and accept or deny them. Once all the policies are reviewed (no one remains in a status TO_REVISE), the IT administrator can go back to zApp installation request panel and click on the “Install App” button. This action calls to the Application Runtime component so that it can deploy the zApp.

Figure 44: Security command centre security policies approval

zApp Manifest

To standardize the specification of a zApp, and to ease integration between the ZDMP components that allow installing zApps, the concept of manifest has been introduced. The manifest defines every aspect of a zApp to allow its security inspections and its later installation and deployment. Below is an example of a manifest file in JSON format.

{
   "zdmp":true,
   "author":"authorName",
   "name":"Electroespindle Monitor zApp",
   "version": "v1.0",
   "description":"Electrospindle Monitor sample zApp",
   "dependencies":[
      "supportApp",
      "bestLibrary",
      "storageMongo"
   ],
   "binaryFile":"bestapp",
   "frontendUri":"/web/index.html",
   "restUri":"/api/",
   "backendUri":"/web/backend.html",
   "configurationUri":"/web/settings.html",
   "iconHDUri":"/web/icon.png",
   "processEndpoints":[
      " "
   ],
   "securityPermissions":[
      {
         "type":"REST",
         "policyName":"Storing electrospindle data",
         "server":"https://zdmp.digitalbusinessplatform.de/apigatewayui",
         "URI":"testAPI",
         "scope":"POST"
      },
      {
         "type":"REST",
         "policyName":"Reading electrospindle data",
         "server":"https://zdmp.digitalbusinessplatform.de/apigatewayui",
         "URI":"testAPI",
         "scope":"GET"
      }
   ]
  }

A zApp manifest contains a set of metadata associated with the application, such as its name, description, author, and zApp version. As for the security, it contains a set of security policies: these are “final resources” that a given zApp is requesting access to. Herein, the zApp states its “intention” within the ZDMP platform. This is stated as a set of permissions that zApps request: eg App “A” requests access to the component “X” to do “Y”. In ZDMP, there are broadly two types of components: (1) REST-full components, and (2) messaging queues (broker). Hence, the security policies would be of either type.

Last modified November 4, 2021