【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ネットワークポリシー編~
SCSK技術者によるブログ!
第27回担当の川杉です。今回はKubernetesのネットワークポリシー機能についてご紹介します。
それでは、参りましょう!
コンテナ(Pod)のネットワーク制御について
KubernetesのPod間通信にはネットワーク制御が不可欠です。システムの規模が拡大すると数百~数千のPodが必要に応じて数を増減させながらKubernetes上で稼働します。大量のPodの管理もさることながらセキュリティの観点ではPodごとにアクセス制限を設けることが重要です。アクセス制限を設けないPodが存在すると思わぬところからアクセスされ攻撃される可能性があります。このアクセス制限のためにKubernetesでは標準機能としてネットワークポリシーというファイアウォール機能を搭載しています。ネットワークポリシーを利用することでPod間通信や、Podと外部ネットワーク間との通信の設定を定義できます。
ネットワークポリシーについて
お客様からたまに聞かれる質問に「Pod間のアクセス制御をSysdigでできないか?」といったものがあります。残念ながらSysdigにはネットワークアクセス制御を実行する機能は存在していません。そんな時はネットワークポリシーをお勧めしています。ネットワークポリシーを利用することでKubernetesクラスタ内のセキュリティを強化し、怪しいトラフィックを防ぐことができます。
ネットワークポリシーはホワイトリスト型のファイアウォールでyamlファイルに書いて定義します。ネットワーク入出力(Ingress/Egress)を下記の要素で制御します。
- Podラベル
- Namespace
- IPブロック(CIDR)
- ポート番号
機能の詳細は以下のURLをご覧ください。
https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/
事前準備
ここからは実際に作成例を見てネットワークポリシーについて理解を深めていきましょう。
まずは早速検証の準備から始めていきましょう。
今回の検証で事前に用意するものは以下の通りです。
- ネットワーク(CNI)プラグインが導入済みであるkubernetes Cluster
※1 kubernetes環境であればなんでもいいです
※2 今回私はOpenshift環境を利用します。その他の環境をご利用の方は環境に応じてkubectlコマンドに置き換えてご検証ください。
いざ検証
今回は動作検証ということで、下記のような環境を作成してみようと思います。
Test-cのnamespaceを指定したネットワークポリシーを作成します。このネットワークポリシーでは、test-aのnamespaceからの通信は許可しますが、test-bからのnamespaceは拒否するように設定します。
※namespaceとNginx Podの作成は割愛します
まずはTest Cのnamespaceで serviceを作成します。
$ oc expose pod nginx-c --port=80 --target-port=80 -n test-c #service作成コマンド service/nginx-c exposed $ oc get all -n test-c #作成確認コマンド NAME READY STATUS RESTARTS AGE pod/nginx-c 1/1 Running 0 10m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nginx-c ClusterIP 172.30.85.32 <none> 80/TCP 10s
上記手順でクラスタ内からのみ通信できるClusterIPタイプでserviceを作成しました。 この状況で疎通確認をしてみましょう。
$ oc exec -it nginx-b -n test-b - bash #execコマンドでnginx-bにシェルイン
root@nginx-b:/# curl 172.30.85.32 #curlコマンドでnginx-cのserviceのipアドレスを指定
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
つながりましたね。まだネットワークポリシーを設定していないのでnginx-bからも想定通りつながりました。
次にネットワークポリシーを作成してみましょう。
今回は、networkpolicy.yamlというファイルで下記のように作成してみました。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ns-test-a
spec:
podSelector: #ネットワークポリシーの対象となるpodをラベル情報で設定
matchLabels:
app: nginx-c
policyTypes:
- Ingress
ingress: #通信の方向を定義。内向きの通信をingress、外向きの通信をegressで設定
- from:
- namespaceSelector: #通信を許可するnamespaceをラベル情報で設定
matchLabels:
kubernetes.io/metadata.name: test-a
前述したとおり今回はtest-a namespaceの通信を許可します。ネットワークポリシーはホワイトリスト型の機能で、設定されたラベルのPodからの通信を許可します
このyamlファイルをdeployします。
$oc apply -f networkpolicy.yaml -n test-c #ネットワークポリシーをデプロイ networkpolicy.networking.k8s.io/allow-ns-test-a created
まずは通信を許可したtest-a namespaceのnginx-a podから通信してみましょう。
$oc exec -it nginx-a -n test-a -- bash
root@nginx-a:/# curl 172.30.55.126
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
接続できましたね!
今度は通信を許可していないtest-b namespaceのnginx-b podから通信してみましょう。
$oc exec -it nginx-b -n test-b -- bash root@nginx-b:/# curl 172.30.55.126 curl: (28) Failed to connect to 172.30.55.126 port 80 after 131374 ms: Couldn't connect to server
ネットワークポリシーの設定どおりにpodの通信を制御できましたね。
今回はかなり基本的な内容で検証しましたが、これを実践的な内容にすると特定のpodやipブロックからの通信のみを許可するなど設定を作りこむことができます。下記は例となります。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: nginx-c-control-networkpolicy
spec:
podSelector:
matchLabels:
app: nginx
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 10.1.0.0/16
ports:
- protocol: TCP
port: 8080
- from:
- podSelector:
matchLabels:
app: frontend-app
ports:
- protocol: TCP
port: 8080
egress:
- to:
- namespaceSelector:
matchLabels:
project: backend-app
ports:
- protocol: TCP
port: 80
この例では、制御対象Podへの内向き(Ingress)の通信として、10.1.0.0/16のIPレンジ、またはapp: frontend-appのラベルが付与されているコンテナからのポート番号8080のTCP通信を許可します。加えて制御対象Podから外向き(egress)の通信として、project: backend-app のラベルを持つnamespace上のコンテナへのポート番号80のTCP通信を許可します。
上記のようにかなり細かく設定できるのはナイスですね!
ただ、Podごとにかなり細かく設定をしようとすると何行にもわたるyamlファイルをいくつも用意する必要があり、管理が大変そうです。そんな時はSysdigが使えます。
実はSysdigで手軽に作成できます
今回ご紹介したネットワークポリシーですが、実はSysdigに作成支援機能があります。グラフィカルな画面でpodへのネットワークトポロジ図を確認したり、Sysdig GUI上でpod通信制御の設定をして、その設定を反映したネットワークポリシーのyamlファイルを生成することができます。この機能を使うことで管理者は何十~何百行にもなるネットワークポリシー定義ファイルの管理や作成業務を軽減できます。本日検証で利用したnginx-cの通信を例に見ていきましょう。
pod間の通信の可視化などもできるので管理がはかどりそうですね。
今回はダイジェストで機能しましたが、もっと詳しい使い方を知りたいという方はこちらもご覧ください。
https://docs.sysdig.com/en/docs/sysdig-secure/inventory/network/policy-generation/
最後に
今回はネットワークポリシーの紹介でした。kubernetesはpod通信を制御するファイアウォール機能がデフォルトで搭載されているため、別途ファイアウォールを用意する必要がない点がいいですね。また、Sysdigと組み合わせて利用することでネットワークポリシー作成のコストを下げられるため、作業負荷を軽減できますネットワークポリシーの管理にお悩みの方はぜひ一度SysdigのPoCを申し込んでお試しください。 それでは、またの機会に!担当者紹介
- 担当者名
- 川杉
- コメント
- 3年ほど前からSysdigを中心にコンテナ・Kubernetes領域で仕事をしています。社内でコンテナ技術の啓蒙活動も積極的に行っています。
- 保有資格
- Certified Kubernetes Administrator
Certified Kubernetes Security Specialist
SCSK技術者ブログ
クラウドにおけるサーバーレスワークロードの保護:Sysdig Secureによるアプローチ
Platform Engineering Kaigi 2025 参加レポート
検知から対応をシームレスに! Sysdigの新機能「Response Action」でインシデント対応を迅速化
【SCSK技術者によるブログ】生成AIでSysdigエージェントのアップグレードを効率化 〜Helm values.yamlの移行作業を自動化〜
【SCSK技術者によるブログ】Sysdigの「Search」機能を体験!生成AIでクエリの学習コスト無しに脆弱性調査
【SCSK技術者によるブログ】ゼロトラスト文脈でのクラウドセキュリティ、そしてSysdig
【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ネットワークポリシー編~
【SCSK技術者によるブログ】生成AIで過検知対策を効率化!Sysdig Sageの実力検証
【SCSK技術者によるブログ】なぜ今、Sysdigが選ばれるのか?動画で解説!クラウドネイティブセキュリティの最前線 - SCSKの日本語伴走サポートで安心導入
【SCSK技術者によるブログ】Serverless AgentがAzure Container Appsに対応しました
【SCSK技術者によるブログ】システムコール分析における生成AIの活用
【SCSK技術者によるブログ】Sysdig情報アップデート~AWS連携にS3オプションが追加されました~
【SCSK技術者によるブログ】Falco初学者講座 - Exceptions編
【SCSK技術者によるブログ】Falco初学者講座 - List/Macro編
【SCSK技術者によるブログ】コンテナの電力消費をSysdig Monitorで監視してみよう
【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~Contianer Drift編~
【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう②
【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう①
【 SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた(Monitor編)
【SCSK技術者によるブログ】Falco初学者講座 - condition編
【SCSK技術者によるブログ】Sysdig Sageを使ってみた
【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編②~
【SCSK技術者によるブログ】Sysdigをセキュアに使おう~IP Allowlist編~
【SCSK技術者によるブログ】Node ExporterをSysdig Monitorに連携してみた
【SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた
【SCSK技術者によるブログ】CNAPPの理解とSysdigのカバレッジ
【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~マルウェア検知編~
【SCSK技術者によるブログ】Sysdigのライセンス体系
【SCSK技術者によるブログ】Sysdig とMicrosoft Entra ID間でSAML認証設定を試してみた
【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編~
【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~AWSサインインなりすまし検知編~
【SCSK技術者によるブログ】Sysdig SecureのRisks機能を試してみた