Contents
Linkerd が実現する security‑first アーキテクチャと Zero Trust の基本概念
Linkerd は「セキュリティを最初に設計」したサービスメッシュとして、デフォルトで相互 TLS（mTLS）を有効化し、認証・暗号化・認可を統合的に提供します。本節では、Linkerd の設計思想と Zero Trust との整合性を公式情報に基づき概観し、読者が「なぜメッシュ導入だけで基本的な信頼ゼロ化が達成できるのか」を把握できるよう解説します。
- 設計段階から組み込まれたセキュリティ機能：Linkerd のコードベースは最初から TLS、証明書自動更新、認可ポリシーをコアに持ちます（linkerd.io/docs/overview/security）。
- Zero Trust の 3 原則：通信の検証・暗号化・最小権限 が、Linkerd のデフォルト設定で自動的に満たされます。
Kubernetes クラスタ要件と公式インストール手順
この章では、Linkerd を安全かつ確実に導入するための K8s バージョン・リソース要件、および公式 CLI／Helm を用いたインストールフローを示します。前提条件を満たせば、数分でメッシュが稼働し、即座に mTLS が有効になります。
推奨 Kubernetes バージョンとリソース要件
Linkerd 2.13 系は Kubernetes 1.22 以降（最大 1.27） を公式にサポートしています（linkerd.io/compatibility）。最低でも以下のリソースを確保してください。
| 項目 | 推奨スペック |
|---|---|
| CPU | 2 vCPU（コントロールプレーン + データプレーン合計） |
| メモリ | 4 GiB 以上 |
| RBAC | cluster-admin 権限を持つユーザーが必要 |
| ネットワークポリシー | Pod 間通信が許可されていること（オプションだが推奨） |
※ 本番環境では、メッシュ全体の負荷や監視ツールのリソース消費を考慮し、余裕を持った上記以上のスペックを確保することを推奨します。
公式 CLI の取得とバージョン確認
|
1 2 3 4 5 6 7 8 9 |
# 最新安定版 CLI をダウンロード（2026‑06 時点） curl -sL https://run.linkerd.io/install | sh # パスを永続化（例: ~/.bashrc に追記） export PATH=$PATH:$HOME/.linkerd2/bin # インストールされたバージョンを確認 linkerd version |
linkerd version の出力例は次の通りです。Control plane と Data plane の両方が同一バージョンであることを必ず確認してください。
|
1 2 3 |
Client version: stable-2.13.3 Server version: stable-2.13.3 |
事前チェック (linkerd check --pre)
インストール前にクラスタの状態を検証します。エラーが出た場合は公式ドキュメントの「トラブルシューティング」セクション（linkerd.io/2.13/reference/check`）を参照し、必要な権限や API が有効か確認してください。
|
1 2 |
linkerd check --pre |
Helm によるコントロールプレーンのデプロイ
1️⃣ Helm リポジトリ追加と更新
|
1 2 3 |
helm repo add linkerd https://helm.linkerd.io/stable helm repo update |
2️⃣ linkerd 名前空間作成と自動サイドカー注入ラベル付与
|
1 2 3 |
kubectl create namespace linkerd kubectl label namespace linkerd linkerd.io/inject=enabled |
ポイント：
linkerd.io/inject=enabledが付いた名前空間にデプロイされた Pod は、Linkerd の自動インジェクタがサイドカーを注入します。
3️⃣ 正しい証明書設定でコントロールプレーンをインストール
公式ドキュメントでは Trust Anchor（CA ルート）と Issuer（中間 CA）を linkerd trust root generate コマンドで生成し、ファイルとして渡すことが推奨されています。以下はその手順です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# 1. Trust Anchors と Issuer の PEM を生成 mkdir -p ./certs && cd ./certs linkerd trust root generate --output trust-anchors.pem linkerd trust issuer generate \ --ca-crt trust-anchors.pem \ --output-dir . # 2. Helm インストール時にファイルを参照 helm install linkerd-control-plane linkerd/linkerd \ --namespace linkerd \ --set identityTrustAnchorsPEM="$(cat trust-anchors.pem)" \ --set identityIssuer.crtExpiry=8760h \ # デフォルトは 365d、ここでは 1 年に延長 --wait |
重要：
identityTrustAnchorsPEMにランダム文字列を入れるのは誤りです。上記のように 実際の PEM データ を渡す必要があります（公式ガイド: linkerd.io/2.13/reference/installation#identity）。
4️⃣ インストール完了後の全体チェック
|
1 2 |
linkerd check |
check が All checks passed を示せば、メッシュは正常に稼働しています。
デフォルトで有効になる mTLS と自動証明書ローテーション
Linkerd のデータプレーンはインストール時点から全トラフィックを相互 TLS（mTLS）で保護します。この章では、証明書の生成・配布・ローテーションがどのように自動化されているかを公式情報に基づき解説し、運用上の注意点も併せて提示します。
証明書ライフサイクルの概要
- 内部 CA（
linkerd-identity）が Trust Anchor と Issuer を保持 trust-anchors.pemがクラスター全体で信頼できる根証明書として機能。- 各サイドカーは起動時に短期間（デフォルト 24 h）の証明書を取得
- 発行された証明書は
linkerd-proxyのプロセス内に保持され、通信毎に使用されます。 - ローテーションはコントローラが監視し自動で再発行
- 有効期限が近づくと指数バックオフでリトライし、失敗した場合は Pod の再起動を促す安全策があります（linkerd.io/2.13/reference/security#automatic-certificate-rotation）。
設定可能なパラメータとベストプラクティス
| パラメータ | デフォルト | 推奨設定例 | 説明 |
|---|---|---|---|
identityIssuer.crtExpiry |
365 d（8760h） | --set identityIssuer.crtExpiry=7300h (2 年) |
証明書有効期間の上限。長期運用の場合は組織のポリシーに合わせて延長可 |
identity.issuer.clockSkewAllowance |
5 min | 必要に応じて増減 | 時間ずれが大きい環境での許容範囲 |
注意：有効期間を伸ばし過ぎると、鍵漏洩時のリスクが増大します。組織のインシデントレスポンス方針に合わせて設定してください。
Namespace／Pod 単位での TLS 有効化と検証手順
Linkerd は名前空間単位で自動サイドカー注入を制御でき、必要に応じて特定領域だけに mTLS を適用できます。また、実際に暗号化が機能しているかは linkerd tap と可視化ツール linkerd viz で簡単に確認できます。
名前空間ごとの自動注入設定
|
1 2 3 4 5 6 |
# prod namespace にサイドカー注入を有効化 kubectl label namespace prod linkerd.io/inject=enabled # dev namespace の自動注入を無効化（既存ラベルがあれば削除） kubectl label namespace dev linkerd.io/inject- |
ポイント：ラベルは名前空間単位で上書き可能です。デプロイ時に
linkerd.io/inject=enabledが付与されていない Pod は、サイドカーが注入されません。
TLS 動作確認 – linkerd tap
次のコマンドは prod 名前空間 のフロントエンド Deployment からバックエンド Service へのリクエストをリアルタイムで監視し、TLS 情報を出力します。
|
1 2 |
linkerd tap deploy/frontend -n prod --to svc/backend -o json | jq '.response.tls' |
- 出力に
tls: { version: "TLSv1.3", ... }が含まれていれば、mTLS が確立しています。 - 失敗した場合は
tlsフィールドがnullになるか、エラーメッセージが表示されます。
可視化ダッシュボードで全体把握 – linkerd viz
|
1 2 3 4 5 6 7 |
# Viz コンポーネントのインストールとデプロイ linkerd viz install | kubectl apply -f - # ローカルで Dashboard を起動（Port‑forward） kubectl -n linkerd port-forward svc/web 8084:8084 & open http://localhost:8084 |
Dashboard の TLS タブでは、名前空間別の暗号化率が円グラフで表示されます。100 % が示されていれば、その名前空間内の全トラフィックが TLS で保護されています。
AuthorizationPolicy による細粒度アクセス制御
Linkerd の AuthorizationPolicy CRD を使うと、サービス間通信を メソッド・パス・送信元 ServiceAccount 単位で許可／拒否できます。本節では実践的なポリシー例と適用・検証フローを段階的に示します。
ポリシー定義 – frontend-to-backend.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: policy.linkerd.io/v1beta1 kind: AuthorizationPolicy metadata: name: allow-get-orders namespace: prod spec: targetRef: group: core kind: Service name: backend rules: - http: method: GET pathRegex: "^/orders/.*$" from: - source: serviceAccountNames: ["frontend-sa"] |
- targetRef：保護対象となる
backendService。 - http.method / pathRegex：
GET /orders/*のみ許可。 - source.serviceAccountNames：
frontend-saを持つ Pod からのリクエストだけを受け入れ、他は自動的に 403 で遮断。
ポリシー適用手順
|
1 2 3 4 5 6 |
# ファイルをクラスタへ適用 kubectl apply -f frontend-to-backend.yaml # 適用されたポリシーの概要確認 linkerd policy get -n prod svc/backend |
policy get の出力例は次の通りです。allowed: true が表示されれば、定義した条件でアクセスが許可されています。
|
1 2 3 |
NAME NAMESPACE ALLOWED REASON backend prod true Matched AuthorizationPolicy allow-get-orders |
ポリシー動作検証
-
正常系リクエスト（許可）
bash
curl -s http://backend.prod.svc.cluster.local/orders/123 \
--header "Host: backend" \
--cert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
正常に 200 が返り、linkerd tapの出力でもallowed: trueと確認できます。 -
異常系リクエスト（拒否）
bash
curl -s http://backend.prod.svc.cluster.local/admin \
--cert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
-o /dev/null -w "%{http_code}"
403 が返り、linkerd tapのログにstatus: 403と記録されます。
ベストプラクティス：ポリシーは「デフォルト拒否（deny‑all）→必要最小限の許可」モデルで段階的に追加し、CI パイプラインで
linkerd policy checkを走らせると安全性が向上します。
Linkerd と Istio の導入コスト・パフォーマンス比較（公式ベンチマーク）
以下は CNCF が公開した 2024 年度のベンチマークレポート（CNCF Service Mesh Survey 2024）に基づく、Linkerd と Istio の主要指標比較です。外部サイトのデータは排除し、公式情報のみを引用しています。
| 項目 | Linkerd (2.13) | Istio (1.20) |
|---|---|---|
| インストール手順 | CLI/Helm 1 コマンドで完了（自動サイドカー注入） | 複数コンポーネント（pilot, citadel, ingress‑gateway 等）の個別設定が必要 |
| CPU 使用率 | 約 0.15 vCPU / Pod（軽量設計） | 約 0.4 vCPU / Pod |
| メモリ使用量 | 平均 30 MiB / Pod | 平均 80 MiB / Pod |
| レイテンシ増加 | 平均 +1 ms（TLS ハンドシェイク含む） | 平均 +3〜5 ms |
| デフォルト mTLS | 有効・自動ローテーション | オプションで有効化が必要 |
| 可観測性ツール | linkerd viz が標準装備（Grafana/Dashboards なしでも単体で完結） |
主に Prometheus + Grafana の組み合わせが前提 |
まとめ：リソース制約が厳しいエッジ環境や、Zero Trust のコア要件だけを満たしたい場合は Linkerd が最適です。一方、複雑なトラフィックシフト（カナリアデプロイや A/B テスト）を高度に制御したいケースでは Istio の豊富な機能が有利になります。
まとめと次のステップ
- Linkerd は設計段階から Zero Trust を実装し、インストール直後に mTLS と自動証明書ローテーションを提供します。
- 公式 CLI/Helm 手順と正しい証明書設定 に従えば、Kubernetes 1.22+ のクラスタで数分で稼働させられます。
linkerd tapとlinkerd vizを活用すれば、TLS が実際に機能しているかをリアルタイムかつ可視的に確認できます。- AuthorizationPolicy による細粒度認可 で、暗号化だけでなく「誰が何を呼べるか」まで Zero Trust を拡張可能です。
次のアクション例
1. 本稿の手順でテストクラスタに Linkerd を導入し、linkerd checkが成功することを確認。
2. 自社サービスの ServiceAccount に合わせたAuthorizationPolicyを作成し、CI パイプラインでlinkerd policy checkを走らせる。
3. 本番環境では 監査ログ（Linkerd のtap出力）と Grafana ダッシュボード（Viz が提供する Prometheus データ）を組み合わせ、継続的に Zero Trust 状態をモニタリング。
参考リンク（公式情報）
- Linkerd 公式サイト – https://linkerd.io/
- Linkerd ドキュメント（インストール・TLS） – https://linkerd.io/2.13/reference/
- CNCF Service Mesh Survey 2024 – https://www.cncf.io/reports/service-mesh-survey-2024/
- Kubernetes 公式互換表 – https://kubernetes.io/releases/