云原生安全与可观测性

云原生环境安全防护:eBPF 安全监控、Falco 运行时威胁检测、服务网格安全、云安全态势管理(CSPM)与可观测性体系建设。

开篇:云原生安全的范式转变

云原生架构(容器、Kubernetes、微服务、Serverless)带来了前所未有的敏捷性和弹性,但也引入了新的安全挑战:容器的短暂生命周期、Pod 之间的东西向流量、动态的自动扩缩容——传统基于边界的安全模型在云原生环境中失效。

本章将介绍基于 eBPF 的内核级可观测性、Falco 运行时威胁检测、服务网格的安全能力,以及云安全态势管理(CSPM)的实施方案。


一、eBPF 安全监控

1.1 eBPF 简介

eBPF(extended Berkeley Packet Filter)允许在内核中安全地运行沙箱程序,无需修改内核源码或加载内核模块。

// eBPF 程序示例:监控系统调用
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

SEC("tp/syscalls/sys_enter_execve")
int trace_execve(struct trace_event_raw_sys_enter *ctx)
{
    u32 uid = bpf_get_current_uid_gid() >> 32;
    
    // 监控 root 用户执行的命令
    if (uid == 0) {
        char comm[16];
        bpf_get_current_comm(comm, sizeof(comm));
        bpf_printk("Root executed: %s", comm);
    }
    
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

1.2 eBPF 安全用例

用例eBPF 程序类型检测能力
网络监控XDP, TCL3/L4 过滤, DDoS 缓解
系统调用追踪Kprobe, Tracepoint进程创建, 文件访问
安全审计LSM Hook权限提升检测
性能分析Perf EventCPU/内存分析

二、Falco 运行时安全

2.1 Falco 规则示例

# falco-rules.yaml
- rule: Unauthorized Privilege Escalation
  desc: Detect privilege escalation attempts
  condition: >
    spawned_process and
    (base64_encoded_command or 
     shell_procs and 
     proc.name in (sudo, su, pkexec))
  output: >
    Privilege escalation attempt detected
    user=%user.name command=%proc.cmdline
  priority: CRITICAL

- rule: Sensitive File Access
  desc: Monitor access to sensitive files
  condition: >
    open_read and
    (fd.name contains "/etc/shadow" or
     fd.name contains "/etc/passwd" or
     fd.name contains ".ssh/id_rsa")
  output: >
    Sensitive file accessed
    user=%user.name file=%fd.name
  priority: WARNING

- rule: Outbound Connection from Database
  desc: Database pods should not make outbound connections
  condition: >
    outbound and
    k8s.pod.label.role = "database" and
    not (fd.sip in (trusted_ips))
  output: >
    Unexpected outbound connection from database
    pod=%k8s.pod.name ip=%fd.sip
  priority: HIGH

一句话总结:Falco 通过系统调用监控检测运行时异常,是 Kubernetes 环境的"入侵检测系统"——它不关心已知漏洞签名,而是检测违反安全策略的行为。


三、服务网格安全

# Istio 安全配置
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # 强制 mTLS
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/web-app"]
  - to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/payments"]

一句话总结:服务网格将安全(mTLS、认证授权、可观测性)下沉到基础设施层,应用无需关心这些横切关注点。


四、CSPM(云安全态势管理)

检查项风险修复建议
S3 Bucket 公开读写数据泄露启用 Block Public Access
IAM 根账户使用权限过大禁用根账户,使用角色
未加密的 EBS/RDS数据泄露启用 KMS 加密
安全组 0.0.0.0/0暴露攻击面最小化入站规则
未打补丁的 EKS AMI已知漏洞启用自动更新

FAQ

Q1: eBPF 与内核模块有什么区别?

eBPF 程序通过验证器检查安全性(不会崩溃内核),而内核模块可能导致内核 panic。eBPF 更适合生产环境的安全监控。

Q2: 服务网格的性能损耗大吗?

Istio 早期版本有显著开销(30-50%),但 eBPF 实现(如 Cilium Service Mesh)将开销降低到 < 5%。


相关阅读

  • https://plumephp.com/security-container-security/ — 容器安全最佳实践
  • https://plumephp.com/security-kubernetes-hardening/ — Kubernetes 安全加固

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「安全」更多文章

  1. Kubernetes安全体系:RBAC、PodSecurity与NetworkPolicy实战
  2. 安全合规与数据保护
  3. 渗透测试与红蓝对抗