2. Knative 架构与安全组件：Serving 与 Eventing 核心组件、安全边界、网络策略基础
2.1 Knative 整体架构与安全边界划分
Knative 在 Kubernetes 之上构建了一层无服务器抽象，其安全边界不仅包含 Kubernetes 原生的 Pod/Service/NetworkPolicy，还引入了 Knative 特有的资源对象与准入控制点。理解 Knative 的架构分层是制定安全基线的第一步。
安全核心观点： Knative 的安全边界遵循“Kubernetes 原生 + Knative 扩展”双层模型。底层依赖 K8s RBAC、Pod Security Standards、NetworkPolicy；上层依赖 Knative 的
spec.config 准入、自动注入的 Istio/ Kourier 网络代理、以及 Eventing 的 Broker/Trigger 授权。
2.2 Knative Serving 核心组件与安全关注点
Knative Serving 负责无服务器工作负载的部署、自动扩缩与流量管理。每个核心组件都有对应的安全配置项。
| 组件 | 职责 | 安全关注点 |
|---|---|---|
| activator | 冷启动时接收流量并缓冲请求，直到 Pod 就绪 | 需限制 activator 的 ServiceAccount 权限；防止 DoS 攻击导致 activator 过载 |
| autoscaler | 基于并发数/CPU 指标决策扩缩容 | 指标数据源需认证；防止恶意指标注入导致异常扩缩 |
| controller | 监听 Knative CRD 变化并协调资源状态 | 必须使用最小 RBAC 权限；禁止 controller 越权操作集群资源 |
| queue-proxy | 注入到每个 Knative Service Pod 的 sidecar，负责流量统计与请求排队 | 需限制 queue-proxy 的容器安全上下文；禁止以 root 运行；只暴露必要端口 |
| net-istio / net-kourier | 网络层实现，提供 Ingress Gateway 与内部路由 | Gateway 需配置 TLS 终止；mTLS 策略；限制外部访问 IP 范围 |
安全实践： 在 Knative Serving 的
config-network ConfigMap 中设置 autoTLS: Enabled 和 httpProtocol: Redirected，强制所有外部流量使用 HTTPS。同时将 default-external-scheme 设为 https。
2.3 Knative Eventing 核心组件与安全关注点
Knative Eventing 提供事件驱动架构，其安全模型围绕事件生产者、Broker、Trigger 和事件消费者之间的信任链展开。
| 组件 | 职责 | 安全关注点 |
|---|---|---|
| Broker | 事件代理，接收并路由事件到匹配的 Trigger | Broker 的 spec.config 需限制可访问的命名空间；防止事件注入攻击 |
| Trigger | 定义事件过滤规则，将事件转发到特定 Sink | Trigger 的 spec.subscriber 必须指向合法的 Service/URI；防止 SSRF |
| Channel | 事件通道，提供事件缓冲与持久化 | Channel 后端（如 Kafka、RabbitMQ）需独立认证；Channel 的访问控制列表 |
| Source | 事件源，将外部事件导入 Knative | ApiServerSource 需限制监听的资源类型；PingSource 需验证事件格式 |
| SinkBinding | 将事件生产者与事件消费者绑定 | 需验证 SinkBinding 的 spec.sink URI 合法性；防止绑定到恶意端点 |
2.4 网络策略基础与 Knative 适配
Kubernetes NetworkPolicy 是 Knative 环境中最基础的网络隔离手段。由于 Knative 的 Pod 生命周期短、IP 动态变化，网络策略的编写需要适配 Knative 的标签体系。
2.4.1 Knative 自动注入的标签
每个 Knative Service 创建的 Pod 会自动携带以下标签，可用于 NetworkPolicy 的 podSelector 匹配：
serving.knative.dev/service：所属 Knative Service 名称serving.knative.dev/revision：所属 Revision 名称serving.knative.dev/configuration：所属 Configuration 名称app.kubernetes.io/name：应用名称（可自定义）
2.4.2 典型网络策略示例
以下策略限制只有 activator 和 istio-ingressgateway 可以访问 Knative Service Pod 的 8080 端口，阻止其他 Pod 直接访问：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-knative-ingress
namespace: my-app
spec:
podSelector:
matchLabels:
serving.knative.dev/service: my-service
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: activator
- podSelector:
matchLabels:
app: istio-ingressgateway
ports:
- protocol: TCP
port: 8080
- protocol: TCP
port: 8443
注意： 如果启用了
queue-proxy 的指标端口（9090、9091），需要在 NetworkPolicy 中显式放通 autoscaler 的访问，否则自动扩缩容会失效。建议在策略中额外添加：from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: knative-serving。
2.4.3 网络策略对比表
| 策略类型 | 适用场景 | Knative 适配要点 |
|---|---|---|
| 默认拒绝所有入站 | 高安全环境，只允许明确放通的流量 | 必须放通 activator 和 ingress gateway 的 IP/标签 |
| 基于命名空间隔离 | 多租户场景，不同团队使用不同命名空间 | 使用 namespaceSelector 限制跨命名空间访问 |
| 基于标签的细粒度策略 | 同一命名空间内不同 Service 之间的隔离 | 利用 serving.knative.dev/service 标签精确匹配 |
| 出口流量限制 | 防止数据泄露，限制 Pod 对外访问 | 需放通 DNS（UDP 53）、Knative 控制面、事件 Broker |
2.5 安全边界总结
Knative 的安全边界可以归纳为以下三个层次，每个层次都需要独立配置与审计：
- 集群边界： Kubernetes RBAC、Pod Security Admission、NetworkPolicy 基础策略
- Knative 控制面边界： Serving/Eventing 组件的 ServiceAccount 权限、ConfigMap 安全配置、CRD 准入 Webhook
- 数据面边界： queue-proxy 安全上下文、用户容器安全策略、mTLS 与网络策略