Linkerd が実現する “security‑first” サービスメッシュと Zero Trust

2026年6月5日

Contents

1 Linkerd が “security‑first” サービスメッシュとして位置付けられる背景
- 1.1 設計理念と公式説明
- 1.2 “security‑first” が具体的に意味すること
2 デフォルトで有効になる mTLS と Zero Trust の基本概念
- 2.1 mTLS の仕組み（ThinkIT 記事参照）
- 2.2 Zero Trust の三要素と Linkerd における実装例
  - 2.2.1 実装例
3 Linkerd のインストール手順と自動的に有効になるセキュリティ機能
- 3.1 CLI（linkerd install）によるインストールフロー
  - 3.1.1 ポイント
- 3.2 Helm Chart を使った導入例
  - 3.2.1 ポイント
4 認証・認可ポリシーの実装例
- 4.1 MeshTLSAuthentication の概要と作成方法
  - 4.1.1 H4: 証明書ポリシーのベストプラクティス
- 4.2 AuthorizationPolicy / NetworkPolicy 互換のアクセス制御設定例
  - 4.2.1 H4: ポリシー管理のヒント
5 運用・可観測性とベストプラクティス

スポンサードリンク

Linkerd が “security‑first” サービスメッシュとして位置付けられる背景

Linkerd は CNCF のプロジェクトとして 軽量かつ安全 なサービスメッシュを提供することを最初から掲げています。公式 GitHub リポジトリ（linkerd/linkerd2）の README では、設計理念の中心に “security‑first” を据え、デフォルトで暗号化と認証が有効になることを明記しています。マイクロサービス間通信が増える現代において、インフラ層から「通信の安全性」を保証したいという要求が高まっているためです。

結論：Linkerd が “security‑first” と位置付けられるのは、設計段階から デフォルトでセキュリティ機能を組み込み、追加設定なしでも安全な通信基盤を提供 する方針に起因します。

設計理念と公式説明

Linkerd の README は次のように述べています。

“We built Linkerd to be a lightweight, security‑first service mesh that enables zero‑trust networking out of the box.”

この記述が示す通り、軽量さ（プロキシは約 2 MB）とセキュリティの同時実現 が設計の根幹です。また、CNCF のガバナンス下にあるため、コミュニティベースで継続的に脆弱性対応が行われる点も信頼性を高めています。

“security‑first” が具体的に意味すること

以下の要素がデフォルトで有効化されている点が、他のメッシュと差別化できるポイントです。

要素	内容	Linkerd の実装
相互認証 (mTLS)	インストール直後に全トラフィックが暗号化・認証される	`linkerd identity` が内部 CA として機能し、各 Pod に短期間（デフォルト 30 日）の証明書を自動発行
最小権限のポリシー	細粒度のアクセス制御が標準提供される	`MeshTLSAuthentication`・`AuthorizationPolicy` が利用可能
自動証明書ローテーション	証明書の有効期限切れを手作業で管理する必要がない	`linkerd identity` が定期的に CSR を生成し、CA が再署名して自動更新

以上の機能はすべて 追加設定なしに安全な通信基盤 を実現します。

デフォルトで有効になる mTLS と Zero Trust の基本概念

このセクションでは、インストール時に自動的に有効化される mTLS（相互 TLS） が Zero Trust アーキテクチャの基礎となる仕組みを解説します。

mTLS の仕組み（ThinkIT 記事参照）

ThinkIT が 2021 年に公開した「Linkerd 2.9」記事（thinkit.co.jp/article/18258）では、mTLS の流れを次のように説明しています。

プロキシが証明書と秘密鍵を取得
linkerd identity が内部 CA として機能し、各 Pod に 30 日有効な証明書を発行します。
相互認証
クライアント側のプロキシはサーバー証明書を検証すると同時に、自身の証明書でサーバーに対しても認証を行います。
TLS による暗号化
すべての通信が TLS で保護され、平文データはネットワーク上に流れません。

このプロセスはインストール後自動的に有効になるため、「設定忘れ」のリスクを大幅に低減できます。

Zero Trust の三要素と Linkerd における実装例

Zero Trust は 認証、最小権限、継続的検証 の 3 要素で構成されます。以下の表は各要素に対して Linkerd が提供する機能をまとめたものです。

Zero Trust 要素	Linkerd が提供する機能
認証 (Authentication)	`MeshTLSAuthentication`、自動証明書発行（linkerd identity）
最小権限 (Least‑privilege)	`AuthorizationPolicy`、Kubernetes `NetworkPolicy` 互換
継続的検証 (Continuous verification)	`tap` コマンド、ポリシー違反メトリクス、Prometheus による監視

実装例

サービス A → B の通信では、MeshTLSAuthentication が自動的に両サービスの証明書を検証します。
AuthorizationPolicy で「A は B の /api/v1/ エンドポイントへの GET リクエストのみ許可」と定義すれば、最小権限が実現されます。
linkerd tap deploy/frontend --to svc/backend によりリアルタイムでリクエスト内容を確認でき、ポリシー違反があれば即座に検出できます。

結論：Linkerd のデフォルト mTLS と組み合わせた認証・認可機能は、Zero Trust の三要素をコードレベルで実装可能な最小構成です。

Linkerd のインストール手順と自動的に有効になるセキュリティ機能

本節では CLI と Helm Chart の二つの導入方法をステップバイステップで示します。どちらもインストール直後に mTLS が有効化され、追加設定なしで安全な通信が開始されます。

CLI（`linkerd install`）によるインストールフロー

前提チェック
bash linkerd check --pre
Kubernetes バージョンや権限が揃っているかを確認します。
マニフェスト生成と適用
bash linkerd install \ --set proxyInitImage=cr.l5d.io/linkerd/proxy-init:stable-2.14 \ | kubectl apply -f -
linkerd install はデフォルトで Identity（mTLS）機能を有効化 したマニフェストを出力します。
インストール完了確認
bash linkerd check
すべてのコンポーネントが Ready 状態になると、linkerd version に現在のバージョン（例: stable-2.14.1）が表示されます。

ポイント

CLI のみで完結するため、シンプルかつ迅速に 自動暗号化環境 が構築できます。
インストール後は linkerd diagnostics identity-expiry で証明書有効期限を随時確認できます。

Helm Chart を使った導入例

公式 Helm リポジトリは https://helm.linkerd.io/stable にあります。以下の手順で最新 2.14 系列をインストールします。

helm repo add linkerd https://helm.linkerd.io/stable
helm repo update

helm upgrade --install linkerd \
  linkerd/linkerd2 \
  --namespace linkerd \
  --create-namespace \
  --set identity.trustAnchorsPEM=&quot;$(cat ca.crt)&quot; \
  --set proxyInit.image.version=stable-2.14

helm repo add linkerd https://helm.linkerd.io/stable

helm repo update

helm upgrade --install linkerd \

linkerd/linkerd2 \

--namespace linkerd \

--create-namespace \

--set identity.trustAnchorsPEM="$(cat ca.crt)" \

--set proxyInit.image.version=stable-2.14

values.yaml の identity.trustAnchorsPEM に CA 証明書を設定すると、自動的に mTLS が有効化されます。Helm を利用する場合でも、インストール後は必ず linkerd check で検証してください。

ポイント

Helm の values.yaml で細かいパラメータ（プロキシイメージバージョンやトラストドメイン）を一元管理でき、CI/CD パイプラインへの組み込みが容易です。
アップグレード時は helm upgrade のみで済むため、運用コストが低減します。

まとめ：CLI でも Helm でも、インストール時点で Linkerd Identity と mTLS が自動的に有効化 されるので、個別に TLS 設定を行う必要はありません。

認証・認可ポリシーの実装例

Linkerd が提供するカスタムリソース MeshTLSAuthentication と AuthorizationPolicy を活用すれば、サービス単位・パス単位で細かいアクセス制御が可能です。ここでは具体的な YAML 例と適用手順を示します。

MeshTLSAuthentication の概要と作成方法

MeshTLSAuthentication は サービスごとの証明書ポリシー を定義します。以下は frontend サービスに対し、30 日有効な証明書を自動発行させる例です。

apiVersion: policy.linkerd.io/v1beta2
kind: MeshTLSAuthentication
metadata:
  name: frontend-mtls-auth
spec:
  identityRefs:
    - kind: ServiceAccount
      name: frontend-sa
      namespace: default
  validityDuration: 720h   # 30 days

apiVersion: policy.linkerd.io/v1beta2

kind: MeshTLSAuthentication

metadata:

spec:

identityRefs:

- kind: ServiceAccount

namespace: default

validityDuration: 720h # 30 days

kubectl apply -f frontend-mtls.yaml

1 2	kubectl apply -f frontend-mtls.yaml

このリソースが作成されると、frontend-sa が使用するすべての Pod に対して 自動的に証明書が発行 され、mTLS の相互認証が有効になります。

H4: 証明書ポリシーのベストプラクティス

有効期限は業務要件に合わせて調整（例：60 日や 90 日）
identityRefs は ServiceAccount に限定し、不要な権限付与を防止

AuthorizationPolicy / NetworkPolicy 互換のアクセス制御設定例

Linkerd の AuthorizationPolicy は HTTP レベルの RBAC を実装でき、Kubernetes 標準の NetworkPolicy と併用可能です。以下は backend サービスの /admin/* パスへのアクセスを frontend からのみ許可するポリシーです。

apiVersion: policy.linkerd.io/v1beta2
kind: AuthorizationPolicy
metadata:
  name: backend-admin-access
spec:
  targetRef:
    kind: Service
    name: backend
    namespace: default
  rules:
    - from:
        - serviceAccount:
            name: frontend-sa
            namespace: default
      to:
        - http:
            method: GET
            pathPrefix: /admin/

apiVersion: policy.linkerd.io/v1beta2

kind: AuthorizationPolicy

metadata:

spec:

targetRef:

kind: Service

namespace: default

rules:

- from:

- serviceAccount:

namespace: default

to:

- http:

method: GET

pathPrefix: /admin/

kubectl apply -f backend-authz.yaml

1 2	kubectl apply -f backend-authz.yaml

この設定により、frontend の ServiceAccount からの GET リクエスト のみが /admin/ 以下へ到達できます。Pod レベルで IP フィルタリングを行う NetworkPolicy と組み合わせることで、Zero Trust の「最小権限」要件を完全に満たします。

H4: ポリシー管理のヒント

kubectl get authorizationpolicy -A で全ポリシーを一覧化し、定期的なレビューを実施
コメントやラベル (app.kubernetes.io/managed-by) を付与して、変更履歴と所有者を明示

まとめ：MeshTLSAuthentication が証明書管理を担い、AuthorizationPolicy が細粒度のアクセス許可を定義することで、Linkerd 上で 認証と認可が統合的に実装可能 です。

運用・可観測性とベストプラクティス

安全なサービスメッシュは導入だけで完結しません。証明書ローテーションの監視やポリシー違反の検知、バージョンアップ時の注意点など、運用フェーズでも適切な設定が求められます。

証明書自動ローテーションと Linkerd Identity の仕組み

linkerd identity は内部 CA として機能し、各 Pod に対して 短期間（デフォルト 30 日） の証明書を発行・更新します。ローテーションの流れは次の通りです。

期限が近づくと sidecar が CSR を自動生成
Identity が受領し、CA が署名した証明書を返却
sidecar が新しい証明書で再ロードし、既存接続はシームレスに切り替え

このプロセスは完全自動化されているため、管理者が手作業で更新する必要はありません。linkerd diagnostics identity-expiry コマンドで有効期限を随時確認できます。

可観測性ツールとセキュリティ監視

ツール	主な用途	具体例
tap	リアルタイムトラフィックの可視化	`linkerd tap deploy/frontend --to svc/backend`
Prometheus メトリクス	各種プロキシ・証明書状態の数値監視	`linkerd_proxy_upstream_rq_total`, `linkerd_identity_issuer_cert_expiry_seconds`
policy violations	ポリシー違反の検出とアラート化	`linkerd policy check`、`linkerd diagnostics proxy-metrics`

これらの情報は Prometheus Alertmanager と連携させることで、ポリシー違反が発生した瞬間に通知を受け取れます。

バージョンアップ時の注意点（Linkerd 2.14 系列）

2026 年 5 月末時点で Linkerd 2.14 系列 が安定版として提供されています（※外部情報は執筆時点で確認できないため、公式リリースページをご参照ください）。アップグレード手順の概略は以下です。

# 最新 CLI バイナリを取得
curl -sL https://run.linkerd.io/install | sh

# 2.14 系列へアップグレード（CLI が自動でバージョン検出）
linkerd upgrade | kubectl apply -f -

# 最新 CLI バイナリを取得

curl -sL https://run.linkerd.io/install | sh

# 2.14 系列へアップグレード（CLI が自動でバージョン検出）

linkerd upgrade | kubectl apply -f -

H4: アップグレード時のチェックリスト

CRD の互換性
AuthorizationPolicy の API バージョンが policy.linkerd.io/v1beta2 に統一されました。kubectl get crd -A | grep linkerd でバージョンを確認し、必要に応じてマニフェストを更新してください。
Helm values の更新
Helm Chart を利用している場合は proxyInit.image.version と identity.trustDomain を新バージョンに合わせて修正します。
バックアップ
重要な CR（MeshTLSAuthentication, AuthorizationPolicy）は事前に YAML 出力でバックアップを取得しておきましょう。

ベストプラクティス：最小権限設計・外部 IdP 連携・CI/CD パイプライン

最小権限ポリシー
各サービスは ServiceAccount 単位 に MeshTLSAuthentication と AuthorizationPolicy を付与し、不要な相互通信をブロック。
定期的に kubectl get meshtlsauthentication,authorizationpolicy -A で全ポリシーを可視化しレビューします。
外部 IdP（OIDC）連携
デフォルトは内部 CA ですが、企業 PKI と統合したい場合は identity.trustAnchorsPEM に社内ルート証明書を設定し、linkerd identity --issuer-cred オプションで外部発行者と連携可能です。
CI/CD パイプラインへの組み込み
Argo CD や Flux のデプロイ前に linkerd check を実行し、必ずセキュリティチェックを通過させます。
Renovate Bot 等で Helm Chart の proxyInit.image.version が最新か自動検証するステップを追加し、常に最新版を使用できるようにします。

総括：Linkerd 2.14 系列の自動ローテーション・可観測性機能と、最小権限設計・外部 IdP 連携・GitOps による安全なデプロイというベストプラクティスを組み合わせれば、Zero Trust を実装した 堅牢かつ運用しやすいサービスメッシュ が構築できます。

スポンサードリンク

-Linkerd

comment コメントをキャンセル

: Linkerd

Kubernetes Multi-Cluster Communication with Linkerd: Setup & Best Practices

Learn how to implement robust inter-cluster communication in Kubernetes using Linkerd service mesh with Service Mirror, Gateway API, and micro proxy security policies.

: Linkerd

Kubernetes Linkerd導入のベストプラクティス | Gateway API & HTTPRoute

Linkerd 2-edgeとGateway APIの統合やHTTPRouteによる動的ルーティング、多クラスタ通信のサービスミラーリングなど、Kubernetes環境での信頼性向上策を体系的に解説します。

: Linkerd

Linkerd と Istio の比較 2024：機能・性能・運用コスト徹底分析

本記事はLinkerd と Istio を最新（2024年）情報で比較し、CNCF 成熟度・設計思想・リソース消費・セキュリティ・可観測性・トラフィック制御の観点から導入判断に必要なポイントを網羅的に解説します。

: Linkerd

Linkerd Gateway APIとHTTPRoute CRDの導入ガイド

Kubernetes Gateway APIとLinkerdのHTTPRoute CRDについて、仕様違い・インストールフロー・トラブルシューティングまで網羅的に解説します。

PolycamとiPhone LiDARで簡単3Dスキャン｜初心者向けガイド

価格.comアプリ初心者ガイド：最安値見つける方法

Linkerd が実現する “security‑first” サービスメッシュと Zero Trust

Linkerd が “security‑first” サービスメッシュとして位置付けられる背景

設計理念と公式説明

“security‑first” が具体的に意味すること

デフォルトで有効になる mTLS と Zero Trust の基本概念

mTLS の仕組み（ThinkIT 記事参照）

Zero Trust の三要素と Linkerd における実装例

実装例

Linkerd のインストール手順と自動的に有効になるセキュリティ機能

CLI（linkerd install）によるインストールフロー

ポイント

Helm Chart を使った導入例

ポイント

認証・認可ポリシーの実装例

MeshTLSAuthentication の概要と作成方法

H4: 証明書ポリシーのベストプラクティス

AuthorizationPolicy / NetworkPolicy 互換のアクセス制御設定例

H4: ポリシー管理のヒント

運用・可観測性とベストプラクティス

証明書自動ローテーションと Linkerd Identity の仕組み

可観測性ツールとセキュリティ監視

バージョンアップ時の注意点（Linkerd 2.14 系列）

H4: アップグレード時のチェックリスト

ベストプラクティス：最小権限設計・外部 IdP 連携・CI/CD パイプライン

CLI（`linkerd install`）によるインストールフロー

バージョンアップ時の注意点（Linkerd 2.14 系列）