4、租户身份管理：租户注册、认证与元数据注入

在多租户容器运行时环境中，日志隔离的第一道防线并非日志存储或传输，而是租户身份。没有可靠的租户身份，后续所有日志路由、访问控制、审计追溯都将失去锚点。本章聚焦于租户从注册到运行时身份注入的完整链路，确保每条日志记录都能被准确归因到发起租户。

4.1 租户生命周期与身份模型

租户身份管理覆盖三个核心阶段：注册（Onboarding）、认证（Authentication）、元数据注入（Metadata Injection）。下表梳理了每个阶段的关键职责与交付物：

4.2 租户注册流程

租户注册是身份管理的起点。一个标准化的注册流程应包含以下步骤：

1. 租户申请：租户管理员通过 API 或 CLI 提交注册请求，包含租户名称、命名空间前缀、配额需求。
2. 身份预配：控制面生成全局唯一的 TenantID（UUID v4），并创建对应的 Tenant CRD 对象。
3. 密钥分发：系统生成初始 API 或 SPIFFE 引导凭证，通过安全通道（如 TLS + 加密响应）返回给租户。
4. 策略初始化：创建默认的日志隔离策略、网络策略、资源配额，并绑定到该租户。
5. 审计记录：将注册事件写入审计日志，包含操作者、时间戳、分配的 TenantID。

# 租户注册请求示例（简化）
POST /v1/tenants/register
Content-Type: application/json

{
  "tenant_name": "fintech-prod",
  "namespace_prefix": "fin-",
  "quota": {
    "pods": 200,
    "log_retention_days": 90
  }
}

# 响应
{
  "tenant_id": "tnt-2a1b3c4d-5678-90ef-gh12-3456789ijklm",
  "api_": "tnt_sk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "initial_policies": ["log-isolation-basic", "network-default-deny"]
}

4.3 认证机制：从 到工作负载身份

容器运行时环境对认证提出了更高要求：不仅需要验证用户或管理面请求，还需要验证工作负载（Pod）的身份。我们采用双层认证模型：

• 管理面认证：租户管理员通过 API 或 OIDC 登录控制面，用于管理日志策略、查看审计日志。
• 数据面认证：Pod 内的工作负载通过 SPIFFE 或绑定的 ServiceAccount 向日志代理证明身份。

下表对比了两种认证方式的适用场景与安全属性：

4.4 元数据注入：将租户身份嵌入运行时

元数据注入是确保日志记录携带租户身份的关键环节。我们采用三层注入策略，从不同维度将 TenantID 写入 Pod 运行时上下文：

1. Downward API 卷注入：通过 Kubernetes Downward API 将 metadata.labels['tenant-id'] 以文件形式挂载到 Pod 内，日志采集器直接读取。
2. 环境变量注入：Admission Webhook 在 Pod 创建时自动注入 TENANT_ID 环境变量，适用于应用层日志框架。
3. Sidecar 代理注入：对于需要加密或转换日志格式的场景，注入日志 Sidecar 代理，代理负责在日志记录中附加租户身份头。

# Pod 创建时 Webhook 注入后的 YAML 片段
apiVersion: v1
kind: Pod
metadata:
  labels:
    tenant-id: "tnt-2a1b3c4d-5678-90ef-gh12-3456789ijklm"
spec:
  containers:
  - name: app
    env:
    - name: TENANT_ID
      value: "tnt-2a1b3c4d-5678-90ef-gh12-3456789ijklm"
    volumeMounts:
    - name: tenant-identity
      mountPath: /etc/tenant
      readOnly: true
  - name: log-sidecar
    image: log-sidecar:latest
    env:
    - name: TENANT_ID
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['tenant-id']
  volumes:
  - name: tenant-identity
    downwardAPI:
      items:
      - path: "tenant-id"
        fieldRef:
          fieldPath: metadata.labels['tenant-id']

4.5 身份注入架构总览

下图展示了从租户注册到运行时元数据注入的完整架构，以及各组件之间的身份流转关系：

4.6 元数据注入的不可篡改性保障

元数据注入面临的最大风险是租户身份伪造。攻击者可能通过修改环境变量或挂载文件来冒充其他租户。我们通过以下机制保障注入数据的可信度：

• Admission Webhook 强制校验：在 Pod 创建时，Webhook 检查 tenant-id 标签是否与控制面记录一致，不一致则拒绝创建。
• 只读挂载 + 不可变标签：Downward API 卷以只读方式挂载；Pod 的 tenant-id 标签通过 metadata.immutable 字段锁定，禁止运行时修改。
• Sidecar 代理签名：日志 Sidecar 在输出日志前，使用租户私钥对日志记录附加数字签名，接收端验证签名确保身份未被篡改。

4.7 本章小结