Introduction

What is SEDIMENT? SEDIMENT (SEcure DIstributed IoT ManagemENT) uses a combination of software root of trust, remote attestation, and resource-efficient cryptography, to build a system that scales across heterogeneous computing platforms. The aim is to provide secure remote attestation framework that can be leveraged for lightweight devices.

What is KubeArmor? KubeArmor is a runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operations) of pods, containers, and nodes (VMs) at the system level. KubeArmor leverages Linux security modules (LSMs) such as AppArmor, SELinux, or BPF-LSM to enforce user-specified policies. KubeArmor generates rich alerts/telemetry events with container/pod/namespace identities by leveraging eBPF.

Our objective is to demonstrate the 5G SBP Use Case - Remote Attestation Use Case 1- IoT Device Security and Authentication, where SEDIMENT RA Verifier and Relying Party are containerized and deployed with KubeArmor providing visibility and protection policies. Initially the result of attestation is used to control access to an example application.  In the future, this may be replaced by a different application, or the attestation may be used to control network access through integration with the 5G ONAP AMF.  The onboarding of the device to be attested is outside the purview of this use case, and a separate use case will address that concern.

Remote Attestation Topology

SEDIMENT System Requirements

• Ubuntu 20.04 docker containers for verifier, relying party,  app server, and prover (surrogate test device)
• Memory: 8 GB
• CPU: 4 VCPUs

• Arch: x86_64

• Networking:  The following TCP ports needs to be open for the corresponding containers

  • Relying Party: 22 (SSH), 8000 and 8101

    • must be able to open connection to 8001

  • Verifier: 22 (SSH), 8100, and 8050 (HTTP GUI)

    • must be able to open connections to 8000

  • Application Server: 22 (SSH), 8001, and 8051 (HTTP GUI)

  • Device: 22 (SSH)

    • must be able to open connections to 8000 and 8100

KubeArmor System Requirements

• CPU: 100m (millicore) 100m = 1/10th of a vcpu (ref)
• Memory: 150Mi (ref)
• karmor cli connects to kubearmor on port TCP/32767.

Deployment Mode

SEDIMENT Deployment Mode

For initial testing, SEDIMENT project will prepare four Docker containers: 

1. SEDIMENT RA Verifier, to be protected using KubeArmor 
2. SEDIMENT RA Relying Party, to be protected using KubeArmor
3. Example application server (to be updated to accept camera feeds from an attested device)
4. A surrogate for the device to be attested (to be later replaced by an actual camera device with SEDIMENT prover)

KubeArmor Deployment Mode

• Deployed in systemd mode
• Discovery Engine provides visibility into app behaviour and runs as host process.

Security use-cases to target with KubeArmor

1. Visibility into SEDIMENT application behavior
1. Identify the process forking behavior of the application
2. Identify sensitive asset access of SEDIMENT
3. Identify network access required by SEDIMENT
2. Protection policies for Gateway deploying SEDIMENT Verifier.
1. Process Whitelisting: Do not allow processes to execute within SEDIMENT container outside of the given spec.
2. Network Access: Only allow SEDIMENT binaries to use the network primitives
3. Check SEDIMENT configuration files and create a security net around SEDIMENT’s sensitive assets.
4. Use host hardening policies to protect host.

Tasks/Action Items

• 25 Apr 2023 Ganesh Venkatraman , what is the status of current IBM environment/solution in Kaloom?
  
  
• Document proposed observability capabilities. Define observability capabilites/use case