Trust Manager

Introduction 

Implementation of self-awareness and Trust Manager systems for monitoring and evaluating the trustworthiness of Infrastructure Elements (IEs).

This repository contains the source code for the Trust Manager, which integrates Orion Broker, Self-Awareness, Self-Security, and Self-Healing modules to calculate a trust score for all Infrastructure Elements within a domain.

Trust Score Structure

The Trust Manager computes three sub-scores:

Reliability Sub-score: Evaluates IE performance and stability
Security Sub-score: Reflects short-term vulnerability based on security alerts
Reputation Sub-score: Captures long-term vulnerability based on historical security issues

The overall trust score (TS) is calculated using:

TS = (Wrep × SBrep) + (Wsec × SBsec) + (Wrel × SBrel) − Penalty

Where:

Wrep, Wsec, Wrel: Weights for Reputation, Security, and Reliability sub-scores
SBrep, SBsec, SBrel: The individual sub-scores
Penalty: Deduction based on self-healing alerts frequency

Communication Flow for Reliability Score

Self-Awareness collects resource usage data (e.g., CPU, memory) from the IE.
It updates the Orion Broker at a set interval.
Trust Manager retrieves the data periodically.
It uses the TOPSIS method to calculate scores and rankings.
Results are written back to Orion-LD and IOTA.

Communication Flow for Security Score

Self-Security sends real-time alerts to the Trust Manager.
Trust Manager calculates an average alert priority, normalizes it, and assigns it as the security sub-score.

Communication Flow for Reputation Score

Self-Security provides historical security data.
Trust Manager computes and normalizes the reputation sub-score.

Features 

Trustworthiness: Ranks IEs based on security and QoS metrics.
Adaptability: Supports attribute and weight customization.

Place in Architecture 

The Trust Manager is a core component that assists the orchestrator in selecting the most trustworthy infrastructure elements.

User Guide 

Trust scores are calculated periodically. A higher score means a more trustworthy IE.

Prerequisites 

Ensure that each Infrastructure Element has a trust score attribute in its data model.

Installation 

You can deploy Trust Manager using Docker Compose, Kubernetes YAML, or Helm.

Deploying via Docker Compose 

Requirements

Docker & Docker Compose
Access to AEROS container registry
manager.ini in configs/
Orion-LD instance

Deployment

docker-compose up -d

curl http://localhost:3000/weights

> Note: Restart container to apply changes in manager.ini.

Deleting

docker-compose down

Deploying via Kubernetes YAML 

Requirements

GitLab repo access
K8s cluster and permissions
kubectl installed
YAML files: - trust-manager-configmap.yaml - trust-manager-deployment.yaml

Deployment

kubectl apply -f trust-manager-configmap.yaml
kubectl apply -f trust-manager-deployment.yaml
kubectl apply -f trust-manager-services.yaml
kubectl get pods -l app=trustmanager
kubectl port-forward deploy/trustmanager 3000:3000
curl http://localhost:3000/weights

Updating Configuration

apiVersion: v1
kind: ConfigMap
metadata:
  name: trustmanager-config
data:
  manager.ini: |
    [General]
    port = 3000
    ...

kubectl apply -f trust-manager-configmap.yaml
kubectl rollout restart deployment trustmanager

Deleting

./delete.sh
kubectl delete -f trust-manager-configmap.yaml
kubectl delete -f trust-manager-deployment.yaml
kubectl delete -f trust-manager-services.yaml

Deploying via Helm 

Requirements

K8s access
Helm v3
AEROS container registry access
Helm chart: ./trustmanager/

Deployment

helm upgrade --install trustmanager ./trustmanager-0.1.0
kubectl get pods
kubectl get svc

Updating Trust Manager

image:
  tag: v2

configManagerIni: |
  [General]
  port = 3001
  ...

helm upgrade trustmanager ./trustmanager-0.1.0
kubectl rollout restart deployment trustmanager

Deleting

helm uninstall trustmanager
kubectl delete configmap trustmanager-config  # if not auto-deleted

Configuration Options 

Configuration is handled through the manager.ini file located in the configs/ folder.

Before deploying the Trust Manager, it’s essential to configure a few mandatory settings to ensure proper integration with your pilot environment and supporting services. These core fields establish connectivity and domain context, and they must reflect your current infrastructure setup to enable seamless operation.

Mandatory Fields 

You must update the following fields:

domain_name: Set this to your pilot’s domain (same as used in Orion-LD).
orion_url, iota_api_url, and iota_node_ip: Ensure these values match your current cluster setup. Update them if your cluster settings differ from the default.

Optional Fields 

The Trust Manager offers a range of optional configuration fields that allow fine-tuning of trust scoring behavior. These settings can be adapted based on the specific requirements of each pilot. The system is fully configurable, enabling users to customize how trust is calculated, how frequently scores are updated, and how different trust dimensions (reliability, security, reputation) are weighted.

This flexibility ensures that the Trust Manager can align with diverse operational environments and pilot objectives. Pilots are encouraged to adjust these parameters to reflect the importance they assign to the reliability, security, and reputation components that make up the overall trust score.

Optional parameters include:

scoreInterval: Time interval for computing the trust score (in minutes)
reliabilityInterval: Reliability score update interval (in minutes)
reputationInterval: Reputation score update interval (in days)
healthPenalty: Penalty applied for each self-healing alert
ReliabilityWeight: Weight of the reliability sub-score
SecurityWeight: Weight of the security sub-score
ReputationWeight: Weight of the reputation sub-score
priorityThreshold: Threshold at which a new trust score is recalculated due to security concerns

Reliability Weights 

Under the [ReliabilityScore] section, you may add or remove Orion-LD properties and assign weights to them. These properties are used in the TOPSIS algorithm to calculate the reliability score.

[ReliabilityScore]
cpucores = 0.2
currentcpuusage = 0.2
ramcapacity = 0.1
availableram = 0.25
currentramusage = 0.25

> Ensure that the total of all weights is less than or equal to 1.0

Developer Guide 

Two APIs are provided:

GET /weights 

Retrieve weight config:

curl http://localhost:3000/weights

POST /calculate 

Run TOPSIS on alternatives.

Request:

{
  "alternatives": [
    [250, 16, 12, 5],
    [200, 16, 8, 3],
    [300, 32, 16, 4],
    [275, 32, 8, 4],
    [225, 16, 16, 2]
  ],
  "weights": {
    "cpu": { "impact": "+", "weight": 0.25 },
    "ram": { "impact": "+", "weight": 0.25 },
    "lel": { "impact": "-", "weight": 0.25 },
    "bel": { "impact": "+", "weight": 0.25 }
  }
}

Response:

{
  "rankings": [4, 3, 1, 2, 5],
  "scores": [
    0.5342768571821003,
    0.4223512916762782,
    0.5776487083237218,
    0.7959914251761436,
    0.07272619042582074
  ]
}

Accessing the APIs 

kubectl port-forward service/trustmanager 3000:80

Trust Manager

Introduction 

Overview 

Trust Score Structure

Communication Flow for Reliability Score

Communication Flow for Security Score

Communication Flow for Reputation Score

Features 

Place in Architecture 

User Guide 

Prerequisites 

Installation 

Deploying via Docker Compose 

Requirements

Deployment

Deleting

Deploying via Kubernetes YAML 

Requirements

Deployment

Updating Configuration

Deleting

Deploying via Helm 

Requirements

Deployment

Updating Trust Manager

Deleting

Configuration Options 

Mandatory Fields 

Optional Fields 

Reliability Weights 

Developer Guide 

GET /weights 

POST /calculate 

Accessing the APIs 

Authors 

License 

Notice (Dependencies)