Istio CNI Unauthorized の原因とトークン期限の確認方法

2026.04.02

はじめに

OpenShift Service Mesh（OSSM）を利用している環境で、アプリケーション Pod が起動せず、 error adding container to network "v2-0-istio-cni": Unauthorizedというエラーが発生するケースがあります。

この問題は Red Hat のナレッジベース（Solution 6995845）にも記載されていますが、OSSM 2.6 でも遭遇したため、症状の概要とトークン有効期限の確認方法をまとめます。

発生した事象：Podが起動しない！

サービスメッシュに参加しているアプリケーション Pod（サイドカー注入が有効なワークロード Pod）が起動できず、イベントに以下のようなエラーが出力されます。

$ oc logs pod -n test-app test-pod
…Failed to create pod sandbox …
…error adding pod ... to CNI network "multus-cni-network"…
…: error adding container to network "v2-6-istio-cni": Unauthorized

OSSM を利用している場合、Istio サイドカー注入前段の Istio CNI プラグインが Unauthorized を返すことで、Pod がネットワーク初期化に失敗し起動しません。

原因：Istio CNIのkubeconfig に入っているトークン期限切れ

原因は、Istio CNI が使用する kubeconfig の ServiceAccount Token 期限切れです。

Istio CNI は、ノード上の次のパスにある kubeconfig（/etc/cni/multus/net.d/v2-6-istio-cni.kubeconfig）を用いてKubernetes API Server と通信します。

この kubeconfig には、Istio CNI 用の ServiceAccount Tokenが埋め込まれており、

このトークンにはデフォルトで 365 日の有効期限が設定されています。

トークンが期限切れになると、

Istio CNI が API Server に認証できない
API が 401 Unauthorized を返す
その結果、Pod がネットワーク初期化に失敗し、起動できなくなる

という状態になります。

OSSM 2.4 以降ではトークンが自動更新される仕様ですが、一部環境では更新処理が正常に走らず、期限切れが発生する場合があるようです。

対処方法：istio-cni-node Pod の再起動

対処方法は、トークンの期限切れに対するistio-cni-node Pod を再起動して kubeconfig を再生成することです。

$ oc get po -n openshift-operators --show-labels 
NAME                                              READY   STATUS    RESTARTS   AGE    LABELS
istio-cni-node-v2-6-9s9mp                         1/1     Running   0          20m    controller-revision-hash=75df6c86df,k8s-app=istio-cni-node-v2-6,pod-template-generation=1,release=istio
istio-cni-node-v2-6-c25tn                         1/1     Running   0          20m    controller-revision-hash=75df6c86df,k8s-app=istio-cni-node-v2-6,pod-template-generation=1,release=istio
istio-cni-node-v2-6-cbcvz                         1/1     Running   0          20m    controller-revision-hash=75df6c86df,k8s-app=istio-cni-node-v2-6,pod-template-generation=1,release=istio
istio-cni-node-v2-6-cp4ft                         1/1     Running   0          20m    controller-revision-hash=75df6c86df,k8s-app=istio-cni-node-v2-6,pod-template-generation=1,release=istio
istio-cni-node-v2-6-gt76g                         1/1     Running   0          20m    controller-revision-hash=75df6c86df,k8s-app=istio-cni-node-v2-6,pod-template-generation=1,release=istio
istio-cni-node-v2-6-v5vrw                         1/1     Running   0          20m    controller-revision-hash=75df6c86df,k8s-app=istio-cni-node-v2-6,pod-template-generation=1,release=istio
istio-operator-544885bfd8-4ggkq                   1/1     Running   0          36m    name=istio-operator,pod-template-hash=544885bfd8

$ oc delete pod -n openshift-operators -l k8s-app=istio-cni-node-v2-6

再起動後、新しいトークンが生成され、さらに 365 日延長されます。

トークン期限の確認方法

本事象が発生した際は、Pod を削除して再起動する前後で、Istio CNI が使用しているトークンの期限を確認することを推奨します。

以下に具体的な確認手順をまとめます。

　１　istio-cni-node-v2-6-xxxが各ノードで起動していることを確認する

$ oc get daemonsets.apps -n openshift-operators
NAME                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
istio-cni-node-v2-6   6         6         6       6            6           kubernetes.io/os=linux   62m

2　対象ノードへ “oc debug” でシェルに入る

$ oc debug node/worker-1
Temporary namespace openshift-debug-46vvh is created for debugging node...
Starting pod/worker-cluster-q2hl7-1-debug-8ksp4 ...
To use host binaries, run `chroot /host`
Pod IP: 10.10.10.20
If you don't see a command prompt, try pressing enter.
sh-5.1# chroot /host

3　以下kubeconfigにistio-cniのtokenが存在することを確認する

[/etc/cni/multus/net.d/v2-6-istio-cni.kubeconfig]

sh-5.1# cat /etc/cni/multus/net.d/v2-6-istio-cni.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1m・・・・・・・・VRFLS0tLS0K
    server: https://172.31.0.1:443
  name: local
contexts:
- context:
    cluster: local
    user: istio-cni
  name: istio-cni-context
current-context: istio-cni-context
kind: Config
preferences: {}
users:
- name: istio-cni
  user:
    token: eyJhbGcX・・・・・・・・・・・6NhyFQ

4　環境変数をセットする

$ echo $TOKEN
$ TOKEN=eyJhbGcX・・・・・・・・・・・6NhyFQ
$ echo $TOKEN
eyJhbGcX・・・・・・・・・・・6NhyFQ

5　ペイロード（２つ目）を取り出してBase64デコードする

$ echo $TOKEN | awk -F. '{print $2}' | base64 -d | jq
{
  "aud": [
    "https://kubernetes.default.svc"
  ],
  "exp": 1802514942,
  "iat": 1770978942,
  "iss": "https://kubernetes.default.svc",
  "jti": "1d85c4e3-7a7b-4111-94eb-b0c0b9623b4b",
  "kubernetes.io": {
    "namespace": "openshift-operators",
　　　　・
　　　　・
　　　　・

6　expを変換する

$ date -d @1802514942
Sat Feb 13 10:35:42 UTC 2027

さいごに

サービスメッシュを利用している環境では、CNI の認証トークンがどのように扱われているか理解しておくことで、今回のようなトラブルに遭遇した際も落ち着いて原因を切り分けることができます。さらに、OSSM2.4 以降は自動更新機能がありますが、実際の現場ではまだ同様の事象が起きているため、定期的な確認や監視をおすすめします。

また、今回紹介したトークン期限の確認方法は、Istio CNI だけでなく、他のコンポーネントや ServiceAccount を使用するさまざまなワークロードでも有効です。

認証トークンに起因するトラブルは Kubernetes 全体で起こり得るため、仕組みと確認方法を把握しておくことは、日常の運用やトラブルシュートにおいて非常に役立つと思います。