Cilium Network Policy

Kubernetesのマニュフェストでパケットコントロールを試してみました。
環境は、下記でテストをしたCiliumをインストールしたものを使います。

Cilium / Container Network Interface


環境) k3s / Ubuntu 18.04

リソースの確認

CiliumNetworkPolicyを使用します。
下記の参考サイトを参考に、POSTのみ許可するマニュフェストを記述しました。

cilium_net.yml

CiliuNetworkPolicyの作成と削除

n@n05:~/work$ kubectl apply -f cilium_net.yml
ciliumnetworkpolicy.cilium.io/nginx01 created
n@n05:~/work$ kubectl get ciliumnetworkpolicy
NAME AGE
nginx01 12s
n@n05:~/work$ kubectl delete ciliumnetworkpolicy nginx01
ciliumnetworkpolicy.cilium.io “nginx01” deleted
n@n05:~/work$ kubectl get ciliumnetworkpolicy
No resources found in default namespace.

作成と削除時のログファイル
/var/log/pods/kube-system_cilium-kcqxh_0c4d1c19-0d7b-4c20-8e43-c3e7c8b38db8/cilium-agent/2.log

2023-03-15T01:24:36.855496089Z stderr F level=info msg=”Policy Add Request” ciliumNetworkPolicy=”[&{EndpointSelector:{\”matchLabels\”:{\”any:app\”:\”nginx\”,\”k8s:io.kubernetes.pod.namespace\”:\”default\”}} NodeSelector:{} Ingress:[{IngressCommonRule:{FromEndpoints:[] FromRequires:[] FromCIDR: FromCIDRSet:[] FromEntities:[] aggregatedSelectors:[]} ToPorts:[{Ports:[{Port:80 Protocol:TCP}] TerminatingTLS: OriginatingTLS: Rules:0xc002d5b7a0}] ICMPs:[]}] IngressDeny:[] Egress:[] EgressDeny:[] Labels:[k8s:io.cilium.k8s.policy.derived-from=CiliumNetworkPolicy k8s:io.cilium.k8s.policy.name=nginx01 k8s:io.cilium.k8s.policy.namespace=default k8s:io.cilium.k8s.policy.uid=c54424d0-e9ec-4563-a5e9-8224c13f0818] Description:Only POST}]” policyAddRequest=1bcaba5f-a13c-43ea-a6b5-bc6a23fa10f2 subsys=daemon
2023-03-15T01:24:36.855535786Z stderr F level=info msg=”Policy imported via API, recalculating…” policyAddRequest=1bcaba5f-a13c-43ea-a6b5-bc6a23fa10f2 policyRevision=12 subsys=daemon
2023-03-15T01:24:36.855538403Z stderr F level=info msg=”Imported CiliumNetworkPolicy” ciliumNetworkPolicyName=nginx01 k8sApiVersion= k8sNamespace=default subsys=k8s-watcher
2023-03-15T01:24:36.855540597Z stderr F level=info msg=”[lds: add/update listener ‘cilium-http-ingress:19444′” subsys=envoy-upstream threadID=440
2023-03-15T01:24:36.95221568Z stderr F level=info msg=”Rewrote endpoint BPF program” containerID= datapathPolicyRevision=11 desiredPolicyRevision=12 endpointID=1640 identity=49865 ipv4= ipv6= k8sPodName=/ subsys=endpoint

2023-03-15T01:24:50.816803005Z stderr F level=info msg=”Deleted CiliumNetworkPolicy” ciliumNetworkPolicyName=nginx01 k8sApiVersion= k8sNamespace=default subsys=k8s-watcher
2023-03-15T01:24:50.816974356Z stderr F level=info msg=”[lds: remove listener ‘cilium-http-ingress:19444′” subsys=envoy-upstream threadID=440
2023-03-15T01:24:50.904837044Z stderr F level=info msg=”Rewrote endpoint BPF program” containerID= datapathPolicyRevision=12 desiredPolicyRevision=13 endpointID=1640 identity=49865 ipv4= ipv6= k8sPodName=/ subsys=endpoint

(どこに出力されるかわからなかったため、/var/log/pods以下、変化のあるファイルをすべて表示。以下のアクセス拒否のときの表示はなかった)

Nginxデフォルト画面にアクセス(Policy作成時と削除時で違いを確認)

k@LK:~$ curl http://192.168.1.181:30080/
Access denied
k@LK:~$ curl http://192.168.1.181:30080/

cilium hubble ui でも確認

アクセスログ(成功時のみ)

n@n05:~/work$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deploy-579f977958-nqhkp 1/1 Running 1 (22d ago) 22d

n@n05:~/work$ kubectl logs nginx-deploy-579f977958-nqhkp -f

192.168.1.181 – – [15/Mar/2023:00:42:54 +0000] “GET / HTTP/1.1” 200 612 “-” “curl/7.68.0” “-”

ログにenvoy-upstreamとあったので、下記調べてみました。

https://github.com/cilium/proxy
https://github.com/cilium/cilium/issues/418

Envoyとは別物と思っていたのですが、そうではないようです。
参考させていただいたサイトにもサイドカーレスについての話題がありましたが、Istioについても下記のような記事がありました。

「Istioが新たな仕組み「Ambient Mesh」を発表。サイドカーなしでサービスメッシュを実現」
https://www.publickey1.jp/blog/22/istioambient_mesh.html

Ciliumはカーネルを積極的につかってK8sで通常のルーティングに使われているiptablesよりも高いパフォーマンスを目指していますが、サイドカーの役割やその関係性についてももっと学習する必要がありそうです。

参考)
「Ciliumを試す -サービスメッシュにサイドカーが必須だと思っていたがそんなことはなかったぜ-」

Ciliumを試す -サービスメッシュにサイドカーが必須だと思っていたがそんなことはなかったぜ-