Contents
Linkerd 2.14におけるセキュリティ機能概要
Linkerd 2.14では、Kubernetesマイクロサービス環境の信頼性向上を目的に、mTLSとRBACの統合が強化されました。この変更により、サービス間通信の暗号化だけでなく、アクセス制御まで一貫したセキュリティ体制を構築できるようになりました。特に側車（サイドカー）構成では、プロキシによる自動認証処理が可能になり、開発者負担を軽減しています。
mTLS/RBAC統合の実務的意義と設計要点
mTLSはサービス間通信の暗号化に加え、相互認証によって信頼できる通信相手だけと接続する仕組みです。これにより、不正アクセスやデータ漏洩リスクを大幅に抑えることができます。RBAC（ロールベースアクセス制御）との統合により、Kubernetesの権限管理と連携して、より細かなアクセス制御が可能になります。
統合設計のポイント
- mTLSとRBACの役割分担: mTLSで通信レベルの信頼性を担保し、RBACでリソースへのアクセス権を管理する
- サイドカー経由での一貫したセキュリティ処理: プロキシがmTLS認証とRBACチェックを同時に行うことで、アプリケーション層の変更不要化
- 最小権限設計との整合性: RBACで定義されたアクセス範囲内でmTLS通信を行うことで、不正利用リスクを抑える
mTLS設定の仕組みと手順
mTLSはLinkerdのプロキシ経由で自動的に有効化される仕組みですが、特定のケースでは手動設定が必要です。以下にステップバイステップの手順を解説します。
証明書生成プロセス
Linkerdはデフォルトで内部CA（認証局）として動作し、証明書を自動生成しますが、独自CAを使用する場合はvalues.yamlに設定が必要です。以下のコマンドで証明書の確認を実施します。
linkerd installを実行して、必要なリソースを作成- CA証明書の内容確認:
bash
openssl x509 -in linkerd-ca.crt -text -noout
注意: Linkerd 2.14ではデフォルトでCA証明書を自動生成しますが、
values.yamlにidentity.issuer.nameやtrustAnchorsのカスタム設定が必要なケースも存在するため、環境に応じた確認が必須です。
パラメータ設定例（Namespace指定付き）
mTLSの有効化には、以下のようなパラメータをYAMLファイルに記述します。Namespace指定を明示的に加えることで最新バージョンとの整合性を保証します。
|
1 2 3 4 5 6 7 |
identity: issuer: name: linkerd-issuers namespace: linkerd trustAnchors: - /etc/linkerd/config/cluster-ca.crt |
RBACとの連携方法
LinkerdとRBACを統合するには、サービスアカウントの権限定義とバインディングの手順に注意が必要です。
Role/ClusterRole定義（Namespace指定付き）
KubernetesではRoleまたはClusterRoleを使って、リソースに対するアクセス制御を行います。以下はLinkerd 2.14で推奨される設定例です。
|
1 2 3 4 5 6 7 8 9 |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: linkerd-proxy rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] |
ServiceAccountのバインディング手順
RBACを有効にするには、ServiceAccountにClusterRoleを割り当てます。以下はNamespace指定付きのコマンドです。
|
1 2 3 4 5 |
kubectl create rolebinding linkerd-proxy \ --clusterrole=linkerd-proxy \ --serviceaccount=linkerd:linkerd-proxy \ --namespace=linkerd |
サービス間通信の暗号化プロセス
サイドカー経由での通信では、TLS終端と信頼済み証明書管理が重要なプロセスです。
TLS終端の動作原理（図解）
| ステップ | 内容 | メカニズム |
|---|---|---|
| 1. | Service A → Linkerd Proxy | mTLS通信開始 |
| 2. | TLS終端処理（Proxy側） | アプリケーションに暗号化データを転送 |
| 3. | Service BでのmTLS認証 | 自動で信頼済み証明書検証実施 |
監視ログの取得方法
Linkerd自体のメトリクスや、セキュリティイベントを監視するためには、Prometheusとの連携が必要です。
メトリクスと監視の重要性
linkerd_proxy_requests_total：通信成功率のモニタリングに不可欠linkerd_proxy_request_duration_seconds：ネットワーク遅延を可視化するための指標
Istioとの比較分析
セキュリティ機能とパフォーマンス特性
| 項目 | Linkerd 2.14 | Istio |
|---|---|---|
| mTLSサポート | 自動有効化（特定環境では手動設定が必要） | 明示的な設定が必須 |
| RBAC連携 | 簡潔なRole定義で実現可能 | 複雑な権限管理構築が前提 |
| セキュリティ設計 | 実装が軽量・シンプル | 標準機能が豊富だが柔軟性が高い |
注意: LinkerdではmTLSの自動有効化がデフォルトですが、ネットワークポリシーによる通信制限やカスタムCA設定を行う際には手動で
values.yamlを調整する必要がある場合があります。
導入コストと導入難易度比較
- Linkerd: 箇条書きリスト形式で比較
- ✅ 設定ファイルがシンプル（10行程度）
- ✅ メトリクス取得が容易（
linkerd vizコマンド使用可） -
❌ 定義済みRBACのカスタマイズには注意が必要
-
Istio: 複雑な設定が必須
- 📦 サービスメッシュとして機能するため、学習コストが高い
- 💡 高度なポリシー管理が可能だが、運用負荷も高め
まとめ
- mTLSとRBACの統合によるセキュリティ体制強化はLinkerd 2.14の最大の特徴です
- サイドカー構成の導入コスト低さが開発者にとっての魅力
- 監視とログ管理の仕組みを整えることで、リスク対応力向上が可能
- Istioとの選択は、運用体制・コスト・柔軟性のバランスに依存します