scenario_http_proxy_single.md

Use Case 1: Client Accessing Single Confidential Computing Node via HTTP Proxy

中文文档

Scenario Overview

• Goal: The client already supports HTTP/HTTPS access to backend services and wants to introduce confidential computing and remote attestation to encrypt the end-to-end link and perform environment verification without changing business code.
• Approach: Deploy a TNG Ingress on the client side as a local HTTP proxy; deploy a TNG Egress inside the server-side confidential computing instance to hijack traffic sent to the backend service via netfilter.
• Effect:
  • The client application only needs to configure an HTTP proxy (or environment variable) without changing the request address;
  • The client-side TNG verifies the trustworthiness of the server-side TNG's environment with the Attestation Service before establishing the tunnel;
  • The server-side TNG decrypts the traffic and forwards it to the local backend service.

Topology Diagram

Client-side TNG (Ingress) Configuration Example

• Ingress Mode: http_proxy
• Remote Attestation Role: verify (verifies the server only)

{
    "add_ingress": [
        {
            "http_proxy": {
                "proxy_listen": {
                    "host": "0.0.0.0",
                    "port": 41000
                },
                "dst_filters": {
                    "domain": "*",
                    "port": 8080
                }
            },
            "verify": {
                "as_addr": "<attestation-service-url>",
                "policy_ids": [
                    "default"
                ]
            }
        }
    ]
}

• Key Points:
  • proxy_listen: The HTTP proxy address configured by the client application, e.g., http://127.0.0.1:41000.
  • dst_filters: Only requests sent to specified domains/ports (any domain, port 8080 in the example) are sent into the TNG tunnel; other traffic is forwarded as a regular HTTP proxy.
  • verify.as_addr: The address of the Attestation Service, to which the client TNG sends the server's attestation materials for verification.
  • policy_ids: Specifies the set of remote attestation policies used, e.g., default.

Server-side TNG (Egress) Configuration Example

• Egress Mode: netfilter
• Remote Attestation Role: attest (acts as the attester)

{
    "add_egress": [
        {
            "netfilter": {
                "capture_dst": {
                    "port": 8080
                },
                "capture_local_traffic": true
            },
            "attest": {
                "aa_addr": "unix:///run/confidential-containers/attestation-agent/attestation-agent.sock"
            }
        }
    ]
}

• Key Points:
  • netfilter.capture_dst.port: The port actually listened to by the backend application (e.g., 8080). TNG will hijack encrypted traffic sent to this port via iptables.
  • capture_local_traffic: When true, it also hijacks traffic with a source IP of the local machine, facilitating the deployment of TNG and backend services within the same confidential computing instance.
  • attest.aa_addr: Points to the local Attestation Agent's Unix Socket address, through which TNG obtains remote attestation materials for the current environment for client-side verification.

Typical Usage Steps

• Client side:
  • Start TNG Ingress, loading the above http_proxy + verify configuration;
  • Configure the HTTP proxy (pointing to proxy_listen) in the browser or HTTP client;
  • Access the original service address normally (no need to change the domain/IP).
• Server side:
  • Deploy backend services in a confidential computing environment and listen on ports (e.g., 8080);
  • Start Attestation Agent and Attestation Service;
  • Start TNG Egress, loading the netfilter + attest configuration, and configure system iptables rules (can be automatically generated by TNG).

When the client initiates a request, it first goes to the local TNG. After passing remote attestation verification, it is sent through an encrypted tunnel to the server-side TNG, then decrypted and forwarded to the backend service, achieving the "HTTP proxy + confidential computing + remote attestation" combined scenario.