AKSでCiliumを導入する前提条件と手順

2026年6月5日

Contents

1 AKS環境におけるCilium導入の前提確認
- 1.1 Linuxノード環境の必須性と実装条件
2 Ciliumのインストール前提条件
3 NetworkPolicyの実装例(L3/L7)
- 3.1 L3ベースのIP制限サンプル
- 3.2 L7ベースのHTTPセキュリティポリシー
4 ポリシー適用後の検証方法
- 4.1 ネットワークトラフィックの可視化コマンド
- 4.2 ポリシーミスのトラブルシューティング
5 Windowsノード環境での代替対応策
- 5.1 代替ネットワークセキュリティソリューションと比較
- 5.2 ポリシー適用範囲の制限方法
6 公式ドキュメントとの併用ポイント
- 6.1 最新版情報の確認手順とリポジトリURL
- 6.2 環境依存設定の検証方法
7 まとめ

スポンサードリンク

AKS環境におけるCilium導入の前提確認

AKS環境でCiliumネットワークポリシーを導入する際には、クラスター構成の基本的な確認が必須です。特にLinuxノード環境に限定される点が重要であり、Windowsノードでは非対応となるため注意が必要です。以下ではクラスターのノード状況確認手順やCilium適用時の制約について詳しく解説します。

Linuxノード環境の必須性と実装条件

CiliumはLinuxカーネルベースのeBPF技術を活用したネットワークポリシー実装ツールであり、Windowsノードでは動作しないことが公式ドキュメントでも明記されています。AKSクラスターにおいては、ノードプールがLinux専用であることを確認する必要があります。

クラスターのノードOS確認手順
以下のコマンドでノードのOS情報を取得できます。
bash kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.osImage}{"\n"}{end}'
出力結果に「Windows」が含まれていれば、Ciliumの導入は不可です。
Windowsノード非対応の注意点
WindowsノードではLinux専用のネットワークドライバやeBPF技術が利用できないため、Ciliumネットワークポリシーの適用が不可能です。既存クラスターにWindowsノードがある場合は、事前にノードプールを分離するか、Linux専用クラスターを作成してください。

Ciliumのインストール前提条件

CiliumをAKS環境で導入するには、いくつかの前提条件があります。特にKubernetesバージョンとRBAC設定の確認が不可欠です。以下に具体的な要件と手順を解説します。

Kubernetesバージョン要件と権限確認

CiliumはKubernetes v1.20以降で動作することが推奨されています。現行AKS環境においては、以下のようにクラスターのバージョンを確認してください。

az aks show -n &lt;クラスタ名&gt; -g &lt;リソースグループ名&gt; --query &quot;kubernetesVersion&quot;

1 2	az aks show -n <クラスタ名> -g <リソースグループ名> --query "kubernetesVersion"

注意: az aks showコマンドの実行にはクラスター管理者権限（admin access）が必要です。

推奨バージョン：v1.20以降（最新版に合わせることを推奨）
非対応バージョン：v1.19以下

RBAC設定確認とクラスターロールのチェック

CiliumはKubernetesのRBAC（Role-Based Access Control）でクラスター管理者権限が必要です。以下のコマンドで確認してください。

kubectl get clusterroles -o jsonpath='{range .items[*]}{.metadata.name}{&quot;\t&quot;}{.rules[0].apiGroups}{&quot;\n&quot;}{end}'

1 2	kubectl get clusterroles -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.rules[0].apiGroups}{"\n"}{end}'

注意: cluster-adminロールを持つユーザーまたはサービスアカウントで操作を行う必要があります。

Helmチャート利用時のリポジトリ設定と最新情報確認

Helmを用いたCiliumの導入に際しては、公式リポジトリへの追加が必須です。以下の手順で事前準備を行います。

Helmリポジトリを追加する
bash helm repo add cilium https://helm.cilium.io/
リポジトリの更新を行う
bash helm repo update

最新情報注意: Cilium CLIやHelmリポジトリURLは公式ドキュメント（https://docs.cilium.io）で確認してください。

NetworkPolicyの実装例(L3/L7)

Ciliumネットワークポリシーは、L3（IPレベル）とL7（アプリケーションレベル）の両方で制御可能です。以下に具体的なYAMLテンプレートとその役割を解説します。

L3ベースのIP制限サンプル

L3ポリシーでは、IPアドレス範囲に基づいた通信制限が可能になります。以下の例は、「特定のIPからのみアクセス許可」を設定するケースです。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l3-ip-restriction-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  ingress:
    - fromCIDR:
        - 192.168.1.0/24
  egress:
    - toCIDR:
        - 10.0.0.0/16

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

name: l3-ip-restriction-policy

spec:

endpointSelector:

matchLabels:

app: my-app

ingress:

- fromCIDR:

- 192.168.1.0/24

egress:

- toCIDR:

- 10.0.0.0/16

endpointSelector：適用対象のPodに設定するラベルを指定します。
fromCIDR / toCIDR：許可されるIPアドレス範囲を定義します。

L7ベースのHTTPセキュリティポリシー

L7ポリシーでは、HTTPヘッダーや特定のURLへのアクセスを制御できます。以下は、「X-API-Keyが指定された場合のみアクセスを許可」する例です。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-http-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  ingress:
    - fromEndpoints:
        - matchLabels:
            tier: frontend
      http:
        headers:
          - key: X-API-Key
            value: &quot;secret-key&quot;

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

name: l7-http-policy

spec:

endpointSelector:

matchLabels:

app: my-app

ingress:

- fromEndpoints:

- matchLabels:

tier: frontend

http:

headers:

- key: X-API-Key

value: "secret-key"

http.headers：特定のHTTPヘッダー値を条件として設定します。

ポリシー適用後の検証方法

Ciliumネットワークポリシーの適用後は、トラフィックが正しく制御されているかを確認する必要があります。主なツールとしてはcilium traceやkubectl get networkpolicyなどがあります。

ネットワークトラフィックの可視化コマンド

cilium trace
クライアントとサーバー間の通信経路をトレースし、ポリシーによる制限が適切に行われているか確認できます。
bash cilium trace <pod-name> -k <key>
kubectl get networkpolicy
適用されたネットワークポリシーの一覧を表示し、定義内容と適用状況を確認します。
bash kubectl get networkpolicy

ポリシーミスのトラブルシューティング

エラーメッセージのチェック
kubectl describe pod <pod-name>でPodのステータスやイベントログを確認し、ネットワークポリシーによって通信が拒否されている場合を特定します。
テスト用トラフィックの生成
指定されたIPアドレス・ポートからのみアクセスを許可するポリシーでは、curlやtelnetなどのコマンドでテスト可能です。

Windowsノード環境での代替対応策

AKSクラスターにWindowsノードが含まれる場合、Ciliumネットワークポリシーの適用はできません。ただし、以下の代替方法を検討することでセキュリティ設計上のリスクを最小限に抑えます。

代替ネットワークセキュリティソリューションと比較

対応方案	特徴	コスト/運用負荷
Azure NSG	AzureのネットワークセキュリティグループによるIPベース制御	高（アサインと管理が手動）
アプリケーションゲートウェイ	ロードバランサーとSSL終端機能を兼ね備えたセキュリティ層	中〜高（初期構成複雑）
カスタムネットワークドライバー	Windowsノード専用のネットワークポリシー実装ツール	低（既存ソリューション利用可能）

注意: Azure NSGやアプリケーションゲートウェイを活用する場合、コスト管理と運用負荷の増加に留意してください。

ポリシー適用範囲の制限方法

Linux専用Namespaceの作成：CiliumネットワークポリシーをLinux専用のNamespaceに限定して設定し、Windowsノードは別途管理します。
ラベルによる除外処理：endpointSelectorでWindowsノードを除外するラベルを指定します（例：tier: backendなど）。

公式ドキュメントとの併用ポイント

Ciliumの最新バージョンや環境依存設定については、公式リソースを参照することが最も信頼できます。以下の手順で情報を収集し、実環境での導入に活かしましょう。

環境依存設定の検証方法

クラスター構成との整合性確認
bash kubectl get nodes -o wide | grep -E 'Linux|Windows'
ポリシー適用前のテスト環境検証（Kubernetes v1.20+とRBACの前提を満たす環境で事前テスト）

まとめ

AKS環境でのCilium導入はLinuxノード専用で実施し、Windowsノードとの併用は避ける
Kubernetesバージョンv1.20以降とRBAC設定の確認が必須である
L3/L7ポリシーをYAMLファイルで定義し、kubectl get networkpolicyなどで適用状況を検証する
WindowsノードではCiliumは非対応であり、代替手段としてAzure NSGやカスタムドライバの活用が重要

公式ドキュメントと併せて実環境で確認しながら設定を進めましょう。