Cilium动手实验室: 精通之旅---29.Discovery: SecOps Engineer

1. Discovery: SecOps Engineer
- 1.1 检查 Cilium 状态
- 1.2 星球大战演示应用程序
- 1.3 可视化流量
- 1.4 网络策略
- 1.5 第 7 层可观测性
- 1.6 相互认证
- 1.7 流加密
2. 使用 Tetragon 实现运行时安全可见性和实施
- 2.1 事件 — 我们受到了攻击！
- 2.2 会审和调查
- 2.3 取证和根本原因分析
- 2.4 夺旗！

1. Discovery: SecOps Engineer

LAB访问地址

https://isovalent.com/labs/discovery-secops-engineer/

1.1 检查 Cilium 状态

验证 Cilium 是否已正确安装并正常运行

root@server:~# cilium status --wait/¯¯\/¯¯\__/¯¯\    Cilium:             OK\__/¯¯\__/    Operator:           OK/¯¯\__/¯¯\    Envoy DaemonSet:    OK\__/¯¯\__/    Hubble Relay:       OK\__/       ClusterMesh:        disabledDaemonSet              cilium                   Desired: 3, Ready: 3/3, Available: 3/3
DaemonSet              cilium-envoy             Desired: 3, Ready: 3/3, Available: 3/3
Deployment             cilium-operator          Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-relay             Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-ui                Desired: 1, Ready: 1/1, Available: 1/1
Containers:            cilium                   Running: 3cilium-envoy             Running: 3cilium-operator          Running: 1clustermesh-apiserver    hubble-relay             Running: 1hubble-ui                Running: 1
Cluster Pods:          7/7 managed by Cilium
Helm chart version:    1.17.1
Image versions         cilium             quay.io/cilium/cilium:v1.17.1@sha256:8969bfd9c87cbea91e40665f8ebe327268c99d844ca26d7d12165de07f702866: 3cilium-envoy       quay.io/cilium/cilium-envoy:v1.31.5-1739264036-958bef243c6c66fcfd73ca319f2eb49fff1eb2ae@sha256:fc708bd36973d306412b2e50c924cd8333de67e0167802c9b48506f9d772f521: 3cilium-operator    quay.io/cilium/operator-generic:v1.17.1@sha256:628becaeb3e4742a1c36c4897721092375891b58bae2bfcae48bbf4420aaee97: 1hubble-relay       quay.io/cilium/hubble-relay:v1.17.1@sha256:397e8fbb188157f744390a7b272a1dec31234e605bcbe22d8919a166d202a3dc: 1hubble-ui          quay.io/cilium/hubble-ui-backend:v0.13.1@sha256:0e0eed917653441fded4e7cdb096b7be6a3bddded5a2dd10812a27b1fc6ed95b: 1hubble-ui          quay.io/cilium/hubble-ui:v0.13.1@sha256:e2e9313eb7caf64b0061d9da0efbdad59c6c461f6ca1752768942bfeda0796c6: 1

1.2 星球大战演示应用程序

现在我们知道 Kubernetes 集群已准备就绪，让我们向其部署应用程序。

endor.yaml 清单将部署一个受《星球大战》启发的演示应用程序，其中包括：

endor 命名空间，包含
具有 2 个副本的 deathstar Deployment（您永远不知道 Death Star 是否会爆炸😬）
用于访问 Death Star Pod 的 Kubernetes 服务
具有 1 个副本的 tiefighter Deployment
具有 1 个副本的 xwing Deployment

使用以下命令部署清单：

kubectl apply -f endor.yaml

然后使用以下命令检查部署：

root@server:~# kubectl get -f endor.yaml
NAME              STATUS   AGE
namespace/endor   Active   2m6sNAME                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/deathstar   ClusterIP   10.96.18.202   <none>        80/TCP    15sNAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/deathstar    2/2     2            2           15s
deployment.apps/tiefighter   1/1     1            1           15s
deployment.apps/xwing        1/1     1            1           15s

执行该命令几次，直到所有部署都标记为完全就绪（例如，对于 Death Star，则为 2/2）。

此应用程序中的服务如何通信？让我们来了解一下！

1.3 可视化流量

请添加图片描述

目前，你在 endor 命名空间中看到三个 Pod 身份：

XWING 用于 XWing 部署中的 Pod
tiefighter 表示 tiefighter 部署中的 pod
DeathStar 表示 DeathStar 部署部署的各种 Pod

tiefighter 和 xwing pod 都会向以下对象发出请求：

Deathstar 服务（HTTP）
disney.com 和 swapi.dev （HTTPS）

Hubble 知道 disney.com 和 swapi.dev 的域名，因为 Cilium 已配置为代理 DNS 流量并缓存来自 Kube DNS 的 DNS 响应，从而提供了一种通过 DNS 名称检查和保护流量的方法。

1.4 网络策略

单击服务地图中的 xwing 框。这将筛选流量以仅显示涉及 xwing 身份的流。

请注意，所有流都以红色部分结尾，表示来自 xwing 身份的流量被丢弃。

您还可以在屏幕底部看到所有流日志，确认来自 xwing 身份的通信已被丢弃。

这是因为 endor 命名空间已使用网络策略进行保护，仅允许特定流量。

单击其中一个日志条目以查看详细信息。您将看到丢弃原因（Policy denied）以及流量方向（egress）。您还将看到基于 Kubernetes 标签的源身份和目标身份的详细信息。

在命令行中使用以下命令查看这些日志：

root@server:~# hubble observe --pod endor/xwing --type policy-verdict
Jun  6 08:00:03.469: endor/xwing-5c4579d865-5sbbf:51308 (ID:6790) -> kube-system/coredns-6f6b679f8f-wwspw:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:03.470: endor/xwing-5c4579d865-5sbbf:56648 (ID:6790) <> swapi.dev:443 (ID:16777219) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:05.475: endor/xwing-5c4579d865-5sbbf:53929 (ID:6790) -> kube-system/coredns-6f6b679f8f-g4p9q:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:05.476: endor/xwing-5c4579d865-5sbbf:33286 (ID:6790) <> endor/deathstar-848954d75c-xhw9n:80 (ID:42205) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:06.479: endor/xwing-5c4579d865-5sbbf:48089 (ID:6790) -> kube-system/coredns-6f6b679f8f-wwspw:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:06.480: endor/xwing-5c4579d865-5sbbf:60122 (ID:6790) <> disney.com:443 (ID:16777218) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:07.484: endor/xwing-5c4579d865-5sbbf:56413 (ID:6790) -> kube-system/coredns-6f6b679f8f-g4p9q:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:07.485: endor/xwing-5c4579d865-5sbbf:33280 (ID:6790) <> swapi.dev:443 (ID:16777219) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:09.489: endor/xwing-5c4579d865-5sbbf:40356 (ID:6790) -> kube-system/coredns-6f6b679f8f-wwspw:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:09.490: endor/xwing-5c4579d865-5sbbf:54818 (ID:6790) <> endor/deathstar-848954d75c-xhw9n:80 (ID:42205) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:10.494: endor/xwing-5c4579d865-5sbbf:35605 (ID:6790) -> kube-system/coredns-6f6b679f8f-wwspw:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:10.496: endor/xwing-5c4579d865-5sbbf:60130 (ID:6790) <> disney.com:443 (ID:16777218) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:11.499: endor/xwing-5c4579d865-5sbbf:47878 (ID:6790) -> kube-system/coredns-6f6b679f8f-g4p9q:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:11.500: endor/xwing-5c4579d865-5sbbf:33294 (ID:6790) <> swapi.dev:443 (ID:16777219) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:13.506: endor/xwing-5c4579d865-5sbbf:35020 (ID:6790) -> kube-system/coredns-6f6b679f8f-g4p9q:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:13.507: endor/xwing-5c4579d865-5sbbf:54820 (ID:6790) <> endor/deathstar-848954d75c-xhw9n:80 (ID:42205) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:14.511: endor/xwing-5c4579d865-5sbbf:60642 (ID:6790) -> kube-system/coredns-6f6b679f8f-wwspw:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:14.513: endor/xwing-5c4579d865-5sbbf:60138 (ID:6790) <> disney.com:443 (ID:16777218) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)
Jun  6 08:00:15.515: endor/xwing-5c4579d865-5sbbf:42166 (ID:6790) -> kube-system/coredns-6f6b679f8f-g4p9q:53 (ID:22051) policy-verdict:L3-L4 EGRESS ALLOWED (UDP)
Jun  6 08:00:15.518: endor/xwing-5c4579d865-5sbbf:43168 (ID:6790) <> swapi.dev:443 (ID:16777219) policy-verdict:none EGRESS DENIED (TCP Flags: SYN)

1.5 第 7 层可观测性

Hubble 具有一个 Web UI，可以实时显示命名空间中 Pod 之间通信的服务地图！

点击 deathstar 框。您可以看到，流量正在进入来自两个 Pod 身份的 Deathstar 身份：Xwing 和 TieFighter。

请注意，该框告诉您，进入 deathstar pod 的流量完全通过端口 80/TCP 进行。

请添加图片描述

编辑并应用策略：

root@server:~# yq policies/deathstar.yaml 
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: deathstarnamespace: endor
spec:endpointSelector:matchLabels:org: empireclass: deathstaringress:- fromEndpoints:- matchLabels:k8s:app.kubernetes.io/name: tiefighterk8s:class: tiefighterk8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name: endork8s:io.kubernetes.pod.namespace: endork8s:org: empireauthentication:mode: "required"toPorts:- ports:- port: "80"protocol: TCPrules:http:- {}
root@server:~# kubectl apply -f policies/deathstar.yaml
ciliumnetworkpolicy.cilium.io/deathstar configured

并观察 deathstar 框现在指示端口 80/TCP 是 HTTP 流量。

您甚至可以看到 /v1/request-landing HTTP 路径是使用 POST 方法调用的！请添加图片描述

这是因为 deathstar Pod 已被注释，以在端口 80 上添加第 7 层可见性。这也可以通过第 7 层网络策略来实现。

单击 tiefighter 框。屏幕底部的所有日志均为绿色，表示允许流量并将其转发到三个目标。

1.6 相互认证

此外，请注意 tiefighter 和 deathstar 之间的片段 boxes 标有 lock 图标 🔒 。

请添加图片描述

这意味着这个特定的流程是通过相互身份验证来保护的，这是这两个身份之间的 Cilium 网络策略中的一个额外参数。

使用以下命令检查 Network Policy：

root@server:~# kubectl -n endor get ciliumnetworkpolicy deathstar -o yaml | yq '.spec'
endpointSelector:matchLabels:class: deathstarorg: empire
ingress:- authentication:mode: requiredfromEndpoints:- matchLabels:k8s:app.kubernetes.io/name: tiefighterk8s:class: tiefighterk8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name: endork8s:io.kubernetes.pod.namespace: endork8s:org: empiretoPorts:- ports:- port: "80"protocol: TCPrules:http:- {}

在 Cilium 中激活相互身份验证就是这么简单！

在 Cilium 中，双向认证是使用 eBPF 在内核级别实现的，而不是依赖 sidecar 代理。这也使其完全透明且与协议无关。

1.7 流加密

相互身份验证通常使用 mTLS 实现，mTLS 同时提供身份验证和流加密。在 Cilium 中，这两个功能都是单独提供的。在这个轨道中，Cilium 被配置为使用 WireGuard 加密流量。

使用以下命令验证此设置：

root@server:~# cilium config view | grep enable-wireguard
enable-wireguard                                  true

这意味着位于集群不同节点上的 Pod 之间的所有流量都将由 WireGuard 加密。

在此设置中，我们还启用了节点到节点加密，因此 Kubernetes 节点上任何进程之间的跨节点通信都将使用 WireGuard 进行加密。使用以下命令检查此设置：

2. 使用 Tetragon 实现运行时安全可见性和实施

2.1 事件 — 我们受到了攻击！

死星安全团队注意到一个死星吊舱爆炸了！

检查它：

root@server:~# kubectl -n endor get pod -l class=deathstar
NAME                         READY   STATUS    RESTARTS        AGE
deathstar-848954d75c-swkkq   1/1     Running   0               21m
deathstar-848954d75c-xhw9n   1/1     Running   1 (2m32s ago)   21m

你会看到 deathstar-848954d75c-xhw9n pod 最近已重启（在 RESTARTS 列中显示为 1）。

可能发生了什么？

让我们检查一下 Pod 的上一个实例的日志：

root@server:~# kubectl -n endor logs deathstar-848954d75c-xhw9n --previous
2025/06/06 07:58:02 Serving deathstar at http://[::]:80
panic: deathstar explodedgoroutine 527 [running]:
github.com/cilium/starwars-docker/restapi.configureAPI.func2.1()/app/restapi/configure_deathstar.go:82 +0x2b
created by github.com/cilium/starwars-docker/restapi.configureAPI.func2 in goroutine 525/app/restapi/configure_deathstar.go:80 +0x1a

看起来死星爆炸了！💥

让我们使用 Hubble 来找出导致这种情况的原因。

2.2 会审和调查

请注意，现在列出了两个 HTTP 请求。新的是 PUT /v1/exhaust-port 。

请添加图片描述

哦不！现在你依稀记得，死星工程师上周告诉你一个涉及死星排气口的已知安全漏洞，并且显然计划修补它。很快。承诺 😬

使用 /v1/exhaust-port 路径过滤条件流向 Death Star：

root@server:~# hubble observe \--to-pod endor/deathstar \--http-path /v1/exhaust-port
Jun  6 08:16:47.903: endor/tiefighter-bbd89f96d-nwqct:47196 (ID:1144) -> endor/deathstar-848954d75c-xhw9n:80 (ID:42205) http-request FORWARDED (HTTP/1.1 PUT http://deathstar.endor.svc.cluster.local/v1/exhaust-port)

它表明此请求来自 tiefighter-bbd89f96d-nwqct pod。

等等 - 这意味着摧毁帝国死星的甚至不是一艘叛军飞船！这是一艘摧毁了自己的帝国船只！（这是有道理的，因为我们之前看到，由于网络策略的实施，X-Wings 不允许访问死星）！

2.3 取证和根本原因分析

我们知道哪个 Pod 被用来发动攻击，但我们能看到那个 Pod 上发生的所有事件吗？

为此，我们需要一个可以在运行时级别为我们提供可观察性的工具。让我们使用 Tetragon，这是一个基于 eBPF 的安全可观测性工具，是 Cilium 系列的一部分。

让我们检查 Tetragon 的日志，查找运行 tiefighter-bbd89f96d-nwqct pod 的节点。

首先找出哪个节点是：

root@server:~# kubectl -n endor get pod tiefighter-bbd89f96d-nwqct -o wide
NAME                         READY   STATUS    RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATES
tiefighter-bbd89f96d-nwqct   1/1     Running   0          30m   10.244.2.149   kind-worker2   <none>           <none>

现在我们知道它在 kind-worker2 上运行，让我们检查并过滤 Tetragon 日志。

找出 kind-worker2 节点上运行的 Tetragon pod：

root@server:~# kubectl -n kube-system get po -l app.kubernetes.io/name=tetragon \--field-selector spec.nodeName=kind-worker2 -o name
pod/tetragon-fqspx

接下来，检查 Tetragon 日志并查找与 /v1/exhaust-port 和 tiefighter-bbd89f96d-nwqct pod 相关的事件。

我们将在节点上的 Tetragon 日志中查找 /v1/exhaust-port 的出现次数，然后将生成的 JSON 日志通过管道传输到映像中提供的 tetra CLI，以显示日志的紧凑彩色视图（而不是原始 JSON）以提高可读性：

root@server:~# kubectl -n kube-system exec -ti pod/tetragon-fqspx -c tetragon -- \sh -c 'cat /var/run/cilium/tetragon/tetragon*.log | \grep /v1/exhaust-port | \tetra getevents -o compact --pods tiefighter-bbd89f96d-nwqct'
🚀 process endor/tiefighter-bbd89f96d-nwqct /usr/bin/curl -s -XPUT deathstar.endor.svc.cluster.local/v1/exhaust-port 
🔌 connect endor/tiefighter-bbd89f96d-nwqct /usr/bin/curl tcp 10.244.2.149:47196 -> 10.244.1.140:80 
🧹 close   endor/tiefighter-bbd89f96d-nwqct /usr/bin/curl tcp 10.244.2.149:47196 -> 10.244.1.140:80 
💥 exit    endor/tiefighter-bbd89f96d-nwqct /usr/bin/curl -s -XPUT deathstar.endor.svc.cluster.local/v1/exhaust-port 0

这些日志包括以下详细信息：

事件类型（进程、网络连接、网络关闭 、进程退出等）
命名空间和 Pod
使用的二进制文件
exec 详细信息（例如，process 的参数、connect 的网络流详细信息等）

您可以通过直接分析 JSON 数据来获取更多详细信息：

root@server:~# kubectl -n kube-system exec pod/tetragon-fqspx -c tetragon -- \sh -c 'cat /var/run/cilium/tetragon/tetragon*.log' | \grep '/v1/exhaust-port' | \jq '.process_exec.process | select(.pod.name=="tiefighter-bbd89f96d-nwqct")'
{"exec_id": "a2luZC13b3JrZXIyOjQ0NTUxNzkzNDgwMjE6MzE3OTM=","pid": 31793,"uid": 0,"cwd": "/","binary": "/usr/bin/curl","arguments": "-s -XPUT deathstar.endor.svc.cluster.local/v1/exhaust-port","flags": "execve rootcwd clone","start_time": "2025-06-06T08:16:47.898250980Z","auid": 4294967295,"pod": {"namespace": "endor","name": "tiefighter-bbd89f96d-nwqct","container": {"id": "containerd://79f9f07358e8d9a833abb84f7ccf9b9c597fb47c65730d858d5fbf56d6e3aea9","name": "starship","image": {"id": "docker.io/tgraf/netperf@sha256:8e86f744bfea165fd4ce68caa05abc96500f40130b857773186401926af7e9e6","name": "docker.io/tgraf/netperf:latest"},"start_time": "2025-06-06T07:58:05Z","pid": 2949},"pod_labels": {"app.kubernetes.io/name": "tiefighter","class": "tiefighter","org": "empire","pod-template-hash": "bbd89f96d"},"workload": "tiefighter","workload_kind": "Deployment"},"docker": "79f9f07358e8d9a833abb84f7ccf9b9","parent_exec_id": "a2luZC13b3JrZXIyOjMzMjc3NDgyMzU0OTU6MTY0ODU=","cap": {"permitted": ["CAP_CHOWN","DAC_OVERRIDE","CAP_FOWNER","CAP_FSETID","CAP_KILL","CAP_SETGID","CAP_SETUID","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_NET_RAW","CAP_SYS_CHROOT","CAP_MKNOD","CAP_AUDIT_WRITE","CAP_SETFCAP"],"effective": ["CAP_CHOWN","DAC_OVERRIDE","CAP_FOWNER","CAP_FSETID","CAP_KILL","CAP_SETGID","CAP_SETUID","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_NET_RAW","CAP_SYS_CHROOT","CAP_MKNOD","CAP_AUDIT_WRITE","CAP_SETFCAP"]},"ns": {"uts": {"inum": 4026533815},"ipc": {"inum": 4026533816},"mnt": {"inum": 4026533827},"pid": {"inum": 4026533828},"pid_for_children": {"inum": 4026533828},"net": {"inum": 4026533662},"time": {"inum": 4026531834,"is_host": true},"time_for_children": {"inum": 4026531834,"is_host": true},"cgroup": {"inum": 4026533829},"user": {"inum": 4026531837,"is_host": true}},"tid": 31793,"process_credentials": {"uid": 0,"gid": 0,"euid": 0,"egid": 0,"suid": 0,"sgid": 0,"fsuid": 0,"fsgid": 0}
}

这些日志还可以轻松导出到您最喜欢的 SIEM，以进行取证分析和警报！

2.4 夺旗！

您是否确定了导致 Death Star 吊舱恐慌发作的二进制文件和参数？

answers.yaml 文件向 Death Star 安全团队提交您的报告。

binary: "/usr/bin/curl"
arguments: "-s -XPUT deathstar.endor.svc.cluster.local/v1/exhaust-port"

然后单击检查按钮完成此挑战！

请添加图片描述

新徽章GET!

请添加图片描述

Cilium动手实验室: 精通之旅---29.Discovery: SecOps Engineer

Cilium动手实验室: 精通之旅---29.Discovery: SecOps Engineer

1. Discovery: SecOps Engineer

1.1 检查 Cilium 状态

1.2 星球大战演示应用程序

1.3 可视化流量

1.4 网络策略

1.5 第 7 层可观测性

1.6 相互认证

1.7 流加密

2. 使用 Tetragon 实现运行时安全可见性和实施

2.1 事件 — 我们受到了攻击！

2.2 会审和调查

2.3 取证和根本原因分析

2.4 夺旗！

相关资讯

热文排行

最新新闻

推荐新闻

热搜词