3. 平台门户架构：门户前端、后端API、Kubernetes API代理、用户身份与权限模型

平台门户是用户与 Kubernetes 集群及 Kyverno 策略引擎交互的统一入口。在审计日志链路中，门户架构决定了日志的生成点、流转路径以及身份信息的附着方式。本章从四层架构出发，解析每一层在审计日志体系中的角色与设计要点。

3.1 四层架构总览

平台门户采用经典的前后端分离 + 代理转发模式，整体分为四层：

3.2 门户前端：操作事件采集

前端层负责捕获用户在界面上的关键操作，生成客户端审计事件。这些事件包含操作类型、目标资源、时间戳和前端会话标识。

• 采集方式：通过 Axios 拦截器或自定义事件总线，在每次 API 调用前后触发日志上报。
• 关键字段：event_type（click/submit/navigate）、target_resource（如 Deployment/Policy）、session_id。
• 上报策略：批量上报 + 离线缓存，避免因网络抖动丢失日志。

{
  "request_id": "req-20250321-abc123",
  "event_type": "submit",
  "target_resource": "Kyverno ClusterPolicy",
  "resource_name": "require-labels",
  "session_id": "sess-xyz789",
  "timestamp": "2025-03-21T10:30:00Z"
}

3.3 后端 API：业务审计日志

后端 API 是审计日志的核心生成层。它接收前端请求，完成业务逻辑处理后，将操作结果与用户身份一并写入审计日志。

3.4 Kubernetes API 代理：请求转发与记录

Kubernetes API 代理层位于后端 API 与 Kubernetes API Server 之间，负责转发请求并记录详细的 API 调用日志。该层是审计日志中技术细节最丰富的部分。

• 代理模式：反向代理 + 请求拦截，支持 WebSocket 和长连接。
• 日志内容：HTTP 方法、请求路径、请求体摘要、响应状态码、响应耗时。
• 安全增强：在代理层注入 X-Audit-Id 头，与后端 API 的 request_id 关联。

# 代理层审计日志示例（JSON 格式）
{
  "request_id": "req-20250321-abc123",
  "proxy_timestamp": "2025-03-21T10:30:01Z",
  "method": "POST",
  "path": "/apis/kyverno.io/v1/clusterpolicies",
  "status_code": 201,
  "duration_ms": 245,
  "user_agent": "portal-backend/1.0",
  "client_ip": "10.0.1.100"
}

3.5 用户身份与权限模型

用户身份与权限模型是审计日志可追溯性的基础。平台门户采用 RBAC（基于角色的访问控制）模型，并扩展了多租户隔离能力。

3.6 身份信息在审计日志中的传递

为确保审计日志的完整性，用户身份信息必须在各层之间可靠传递：

1. 前端 → 后端：通过 JWT 携带用户身份，后端解析 提取 user_id 和 tenant_id。
2. 后端 → API 代理：在 HTTP Header 中注入 X-User-Id 和 X-Tenant-Id，代理层记录这些字段。
3. API 代理 → Kubernetes：使用 ServiceAccount 或 Impersonation 机制，将用户身份映射为 Kubernetes 用户。