What type of PR is this?

What does this do?

Architecture Changes and Future Splits

Current Architecture Changes

The cocos-agent has been refactored to separate the hardware attestation logic into a dedicated component: attestation-service.

1. Attestation Service: A standalone service running as attestation-service systemd unit.

   • Responsibility: Interacts directly with CVM hardware (TPM/TDX/SNP) to generate attestation quotes and fetch Azure tokens.
   • Interface: Exposes a gRPC interface over a Unix Domain Socket (/run/cocos/attestation.sock).
   • Security: Runs with privileges required for hardware access, isolated from the agent's complex workload logic. This follows the principle of least privilege.

2. Agent (Coordinator): The main cocos-agent process.

   • Responsibility: Coordinations computations across the cluster. Managing workloads, verifying manifests, and communicating with the Manager.
   • Attestation: No longer interacts directly with /dev/tpm or /dev/sev. Instead, it connects to the attestation-service via gRPC to request attestation reports.
   • Benefit: Reduced attack surface. If the agent is compromised by a malicious workload, it cannot directly manipulate the attestation hardware.

Future Component Splits

To further enhance security and modularity, the following components are proposed to be split from the monolithic agent:

1. Egress Scrutinizer / Networking Proxy

• Goal: Control and monitor all network traffic leaving the CVM.
• Implementation: A separate process or sidecar acting as a transparent proxy.
• Function: Enforce allow-lists for network connections, logging all egress traffic. The agent would route traffic through this component.

2. Computation Runner / Workload Executor

• Goal: Isolate the execution of user algorithms (Python, Binary, Wasm).
• Implementation: A "sandbox" or runner service.
• Function: The agent would submit the algorithm and data specifics to the Runner. The Runner executes the code in a highly restricted environment (e.g., using seccomp, namespaces, or nested VMs/containers) and returns only the result. This protects the agent (coordinator) from crashes or exploits in user code.

3. Log/Event Forwarder

• Goal: Robust and secure log exfiltration.
• Implementation: A dedicated logging sidecar.
• Function: Buffers logs and events from Agent and other components, ensuring guaranteed delivery to the Manager/Logging service, handling retries and encryption independent of the main agent logic.

Diagram (Simplied)

graph TD
    Hardware[Hardware TPM/TDX/SNP]
    AttSock[Attestation Socket /run/cocos/attestation.sock]
    
    subgraph PrivilegedLayer["Privileged Layer"]
        AttSvc[Attestation Service]
    end
    
    subgraph WorkloadLayer["Workload Layer"]
        Agent[Agent Coordinator]
    end
    
    AttSvc -->|Controls| Hardware
    AttSvc -->|Listens| AttSock
    Agent -->|Connects| AttSock

Which issue(s) does this PR fix/relate to?

• Related Issue #
• Resolves #

Have you included tests for your changes?

Did you document any new/modified feature?

Notes