📚 课程目录第3章安全基线概念

3. 安全基线概念：Pod安全策略、网络策略、RBAC策略在KEDA环境中的基线定义

在KEDA驱动的云原生环境中，安全基线是保障自动缩放工作负载安全运行的最低安全要求集合。KEDA通过监听外部事件源（如Prometheus、Kafka、RabbitMQ）来驱动HPA（Horizontal Pod Autoscaler）进行Pod的冷启动与削峰操作。这种动态的、事件驱动的缩放行为，使得传统的静态安全策略面临新的挑战。本章节将定义在KEDA环境下，Pod安全策略、网络策略以及RBAC策略的核心基线。

3.1 KEDA环境安全基线的三大支柱

KEDA环境的安全基线并非独立存在，而是与Kubernetes原生安全机制深度耦合。我们将从以下三个维度构建基线：

Pod安全基线：确保由KEDA触发创建的Pod运行在最小权限的上下文中，防止容器逃逸与权限提升。
网络策略基线：定义KEDA组件（Operator、Metrics Server、ScaledObject）与目标工作负载之间的最小网络连通性，限制东西向流量。
RBAC策略基线：精确控制KEDA组件对Kubernetes API资源的访问权限，以及ScaledObject对事件源（如Kafka、Prometheus）的访问凭证。

    关键认知： KEDA的“冷启动”与“削峰”特性要求安全基线必须支持动态策略的快速生效与回收。例如，当KEDA根据事件压力创建新的Pod副本时，该Pod必须立即继承预定义的网络隔离与安全上下文，无需人工干预。

3.2 Pod安全策略基线（PSP / Pod Security Standards）

在KEDA环境中，Pod安全策略主要关注由ScaledObject触发创建的Pod。由于这些Pod的生命周期完全由事件驱动，其安全上下文必须通过基线进行严格约束。

安全维度	基线要求	KEDA场景说明
容器用户	禁止以root用户运行；必须指定非0的runAsUser	KEDA创建的Pod应使用专用ServiceAccount，并强制应用Pod Security Admission的“restricted”级别
特权模式	禁止privileged: true；禁止添加CAP_SYS_ADMIN等危险能力	KEDA工作负载通常为无状态应用，无需特权模式；若需特殊能力，需通过白名单显式声明
文件系统	只读根文件系统（readOnlyRootFilesystem: true）；禁止挂载宿主机敏感路径	防止KEDA Pod在冷启动时写入恶意文件或读取宿主机凭证
Seccomp/AppArmor	启用RuntimeDefault或Localhost配置文件	限制KEDA Pod的系统调用，降低容器逃逸风险

实践建议： 在KEDA的ScaledObject定义中，通过template.spec.securityContext字段直接嵌入Pod安全基线。避免依赖集群级别的PodSecurityPolicy（已弃用），优先使用Pod Security Admission（PSA）的命名空间标签。

# KEDA ScaledObject 示例：嵌入Pod安全基线
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: secure-app-scaler
spec:
  scaleTargetRef:
    name: my-app
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: sum(rate(http_requests_total[1m]))
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 60
  # 安全基线嵌入点
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: my-app
          securityContext:
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

3.3 网络策略基线

KEDA环境中的网络策略基线需要覆盖两个层面：KEDA控制面组件（Operator、Metrics Server）之间的通信，以及KEDA与目标工作负载之间的流量路径。基线目标是实现“默认拒绝，按需放行”。

基于上述流量路径，网络策略基线定义如下：

入站规则（Ingress）：目标工作负载的命名空间应配置NetworkPolicy，仅允许来自KEDA Operator和Metrics Server的Pod IP段的入站流量。
出站规则（Egress）：KEDA组件（Operator、Metrics Server）应仅允许出站到目标工作负载的Pod IP段及事件源（如Prometheus Server）的IP段。
隔离策略：KEDA组件应部署在独立的命名空间（如keda-system），并应用“默认拒绝”的命名空间级网络策略。

# 目标工作负载命名空间的网络策略示例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-keda-ingress
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: keda-system
          podSelector:
            matchLabels:
              app.kubernetes.io/name: keda-operator
      ports:
        - protocol: TCP
          port: 8080  # 业务端口
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: keda-system
          podSelector:
            matchLabels:
              app.kubernetes.io/name: keda-metrics-apiserver
      ports:
        - protocol: TCP
          port: 8080  # 指标端口

3.4 RBAC策略基线

KEDA的RBAC基线需要覆盖两个核心主体：KEDA组件自身（Operator、Metrics Server）对Kubernetes API的访问权限，以及ScaledObject对事件源（如Kafka、Prometheus）的访问凭证。基线原则是“最小权限，按需授予”。

RBAC主体	资源/操作	基线要求	KEDA场景说明
KEDA Operator	ScaledObject, ScaledJob, TriggerAuthentication	get, list, watch, update, patch	Operator需要监听ScaledObject的变化，并更新HPA对象
KEDA Metrics Server	HorizontalPodAutoscaler, Pod	get, list, watch	Metrics Server需要读取HPA和Pod信息以提供指标
ScaledObject (目标工作负载)	事件源凭证 (Secret)	仅允许通过TriggerAuthentication引用	禁止将事件源凭证直接硬编码在ScaledObject中；必须通过Secret或Vault注入
集群管理员	ClusterRole, ClusterRoleBinding	仅允许在keda-system命名空间内创建	防止KEDA组件权限被滥用，影响集群其他命名空间

安全风险提示： 如果KEDA Operator的RBAC权限过于宽泛（例如授予了cluster-admin），攻击者一旦通过KEDA的Webhook漏洞或配置错误获得控制权，将能够操纵集群中任意命名空间的Pod缩放行为，甚至创建特权Pod。务必使用专用ServiceAccount并绑定最小权限的ClusterRole。

# KEDA Operator 最小RBAC权限示例
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: keda-operator-role
rules:
  - apiGroups: ["keda.sh"]
    resources: ["scaledobjects", "scaledjobs", "triggerauthentications"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: ["autoscaling"]
    resources: ["horizontalpodautoscalers"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods", "services", "endpoints"]
    verbs: ["get", "list", "watch"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: keda-operator
  namespace: keda-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: keda-operator-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: keda-operator-role
subjects:
  - kind: ServiceAccount
    name: keda-operator
    namespace: keda-system

3.5 基线在冷启动与削峰场景中的动态生效

KEDA的冷启动（从0到1）和削峰（从N到M）操作，要求安全基线必须能够动态、一致地应用于新创建的Pod。以下是基线在KEDA生命周期中的生效流程：

事件触发：KEDA ScaledObject检测到事件源指标超过阈值。
HPA创建/更新：KEDA Operator创建或更新HPA对象，HPA根据指标计算期望副本数。
Pod创建：Kubernetes ReplicaSet根据HPA指令创建新的Pod副本。
安全基线注入：KEDA Operator的Mutating Webhook拦截Pod创建请求，根据ScaledObject中定义的template.spec.securityContext注入Pod安全基线。
网络策略生效：新Pod的标签与预定义的NetworkPolicy匹配，自动继承网络隔离规则。
RBAC验证：新Pod使用其绑定的ServiceAccount访问事件源，Kubernetes API Server验证其RBAC权限。

基线验证建议： 在KEDA的ScaledObject中设置advanced.horizontalPodAutoscalerConfig.behavior.scaleDown.stabilizationWindowSeconds，为削峰后的Pod回收提供冷却时间。在此期间，安全基线（如网络策略）应保持生效，直到Pod完全终止。

通过上述Pod安全、网络策略和RBAC策略的三维基线定义，KEDA环境能够在动态缩放过程中维持一致的安全态势，确保冷启动与削峰操作不会引入安全漏洞。