开篇:云原生安全的范式转变
云原生架构(容器、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, TC | L3/L4 过滤, DDoS 缓解 |
| 系统调用追踪 | Kprobe, Tracepoint | 进程创建, 文件访问 |
| 安全审计 | LSM Hook | 权限提升检测 |
| 性能分析 | Perf Event | CPU/内存分析 |
二、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 安全加固
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。