サービスメッシュのLinkerd、Pod間通信にオーソライゼーションポリシーを実装

サービスメッシュを実現するLinkerdの開発主体であるBuoyantが、最新バージョンの2.11の解説動画を公開した。今回の動画は新しく導入されたオーソライゼーションポリシーに関する解説を、デモを交えて行ったもので、セッションに登壇したのはBuoyantのCEOであるWilliam Morgan氏と、テクニカルエバンジェリストであるJason Morgan氏だ。

タイトルは「LinkerdでKubernetesクラスターをロックダウンする方法」

約1時間の動画の前半は解説、後半はサービスメッシュの実装例として使われるスマートフォンで絵文字を選んで投票する「Emoji.voto」というデモアプリケーションに対してオーソライゼーションポリシーを適用するという内容となっている。またハンズオンワークショップとしてリアルタイムで質問を受け付け、それに対して回答するという内容が含まれているため、やや冗長となっている。前回、William Morgan氏にインタビューした際に説明されていた、ポリシーによるセキュアな通信の実装を丁寧に解説している。ちなみに登壇した二人ともMorganという姓だが、血縁関係はないという。

2021年8月に行ったWilliam Morgan氏へのインタビュー：サービスメッシュのLinkerdの最新リリースと将来計画をBuoyantのCEOが解説

動画：Locking down your Kubernetes cluster with Linkerd

オーソライゼーションポリシーとは

Linkerd 2.11で導入されたオーソライゼーションポリシーの解説

まず前提として、どうしてこのポリシーが必要となったのか？について解説を行った。ここではKubernetesもLinkerdも、デフォルトではすべてのコミュニケーショントラフィックがまったくの制限なく行われるということを説明。つまり性善説的な発想でKubernetesもLinkerdも開発されていると言える。

デフォルトではKubernetesもLinkerdも全てのPodと制限無く通信が可能

そして今回のオーソライゼーションポリシーについて、基本的にはすべての通信を制限した上で許可された通信だけを行うという設計になっており、要は「オーソライズされた通信だけを可能にするポリシー」という発想で作られたことを解説した。

通信はサーバー側（送信する時のみ）に制限をかける方法

このスライドでは2.11での実装について解説しており、ここではサーバーサイド、つまりメッセージを送る側に制限をかける方式になっていることを説明。メッセージの中身で制限を行うのではなく、コネクションを制限するという形になっているという。ただし、これは最初の実装であり、2.12以降で受信側の制限やメッセージの内容に応じた制限を行う処理を実装する予定になっていることも合わせて説明した。

ネットワークポリシーとの違いを解説

次のスライドではネットワークポリシーとの違いを解説。ネットワークポリシーの特徴であるIPアドレスなどのID情報による制限、暗号化機能を持たない点などとの違いを強調し、より詳細なPod間の通信制限を行うためにはLinkerdのレベルで行うことが必要だということを示している。

オーソライゼーションポリシーはCRDによって実装されている

ここではデフォルトポリシーとKubernetesをカスタマイズする際に利用されるCRD（Custom Resource Definition）によって実装されていることを説明しているが、ここでLinkerdが利用するCRDが4つに増えてしまったと言っているのは、安易にCRDを作りがちなKubernetesエコシステムへの皮肉かもしれない。

デフォルトポリシーが適用されるタイミングなどを解説

デフォルトポリシーが適用されるタイミングや範囲などをこのスライドでは説明している。次のスライドでデフォルトポリシーの内容を解説し、「deny」を指定するとはすべてのコネクションが制限されることを説明した。

デフォルトポリシーの説明

アプリケーションを使ってオーソライゼーションポリシーの記述例を解説

ここからサービスメッシュのデモで利用されるEmoji.votoというアプリケーションを使って、Linkerdの設定内容を見せながらオーソライゼーションポリシーの具体的な記述例を解説した。

サーバーが「Web」サービスアカウントからのコネクションを許可する際の設定例

次のスライドではLinkerdがコネクションを許可する際のロジックを解説。ここではサーバーへの設定がある場合はその設定によって判断し、設定がない場合にはデフォルトポリシーに従って制限を行うかどうかを決めるというロジックを解説している。

Linkerdが許可する際のロジックを説明

また許可されなかった場合にどのようなエラーが返るのかを説明している。

Linkerdが返すエラーに関する解説

また「基本は拒否（Deny-all）」を選択した際の注意点として、Kubeletが行う通信についても影響を及ぼしてしまうこと、認証がデフォルトの場合にはKubeletの通信は平文のテキストによって認証なしの通信になってしまうことを説明した。他にもいくつかの注意点があることにも留意されたい。

オーソライゼーションポリシーの注意点を解説

ここからはBuoyantが公開しているブログ記事、Go directly to namespace jailという記事に沿って、オーソライゼーションポリシーの設定を行うデモの時間となった。

ブログ記事に従って実際に設定を行う

ここで参照されたブログ記事は以下のものだ。

参考：Go directly to namespace jail: Locking down network traffic between Kubernetes namespaces

またデモで利用されたアプリケーションはGitHubのページを参照されたい。

デモアプリ：Emoji.voto https://github.com/BuoyantIO/emojivoto

デモはBuoyantが提供しているSaaS版のLinkerdであるBuoyant Cloudを使って行われている。

Buoyant Cloudを使って設定のデモを実施

今回はハンズオンのワークショップとして公開された動画をベースに紹介したが、2021年からポリシーの実装を語っていたWilliam Morgan氏が約束通りに実装し、その内容を具体的に解説する内容となった。2.11では送信側のみの実装となったが、受信側での実装など機能拡張は続いていくようだ。

今やバズワードを通り過ぎた感があるサービスメッシュだが、地味にエンタープライズが求める機能要件を着実に実装しているのは評価するべきだろう。