KubeCon North America 2024から、TikTokが解説するマルチクラウドでのアクセス管理実装の解説セッションを紹介

KubeCon＋CloudNativeCon North America 2024から、マルチクラウド上に存在するKubernetesクラスターに対する認証及びアクセス管理の実装を解説したセッションを紹介する。解説するのは、ショート動画サービスのTikTokのEdge Platform TeamのTech LeadであるNaveen Mogulla氏だ。

「複数のクラウドに実装されたKubernetesへのOpen ID Connect（OIDC）アクセスの実装例」という内容のセッション

プレゼンテーションを行うMogulla氏

最初にMogulla氏は所属するEdge Platform Teamの紹介を行った。ここではバックエンドに対するフロントエンドという意味で「エッジ」という名称が使われていると思われる。Content Delivery Networkやストリーミング、ユーザーが行うアップロードなどの処理を受け持つのがエッジ、つまりフロントエンドということだろう。ちなみに後で簡単に説明されているが、TikTokのデータベースはOracle上に実装されているという。

TikTokのフロントエンド側のエンジニアリングチームの所属

TikTokがマルチクラウドの実装に至る前はオンプレミスでのKubernetesがメインだったが、マルチクラウドに移行した背景を解説。

マルチクラウドに至るまでの経緯を紹介

マルチクラウドの前にパブリッククラウドを使った理由として、インフラストラクチャーに対する耐障害性や即座に実装できることなどを挙げた。またマルチクラウドについては国や地域によって法規制が存在することを挙げている。これはデータの所在などについてGDPRなどの法規制を想定した条件ということだろう。

2024年にバイデン政権が、TikTokのアメリカ国内での利用を制限する法律を成立させたことなども関係してくると思われる。地域やプロバイダーをまたがってアプリケーションやデータを移動させる必要性から、マルチクラウドに移行するのは必要な要件だろう。このセッションを行ったNaveen Mogulla氏は、LinkedInのプロフィールによれば2024年12月にTikTokの運営元であるByteDanceを退社しており、2024年11月のKubeConのセッションが最後の登壇になったと思われる。アメリカでのTikTokが政権によって制限されるのであれば、運用だけではなくソフトウェア開発も収縮していくであろう。Mogulla氏の転職もその影響かもしれない。またデータベースを担っているOracle Cloud Infrastructureにしても、TikTokという巨大な顧客を失うことは重大な事態だろう。

マルチクラウドの問題点を整理。ここからはアクセス管理を解説

マルチクラウドでの運用サイドの問題点を整理したスライドでは、マネージドサービスの違いや実装の違い、シークレット管理などについて挙げた。その中でもこのセッションではアクセス管理について解説すると説明した。

まずクラウド前のシステムとしてはオンプレミスでのマルチクラスター実装となっており、そこではKeycloakを利用していたことを解説。Keycloakを使ってOpenID Connectでのアクセス管理を行っていたと説明した。

Keycloakを使って複数のKubernetesクラスターにアクセス

そしてそこからGCPが提供するGKE（Google Kubernetes Engine）と、AWSが提供するEKS（Elastic Kubernetes Service）、そしてOracleが提供するOKE（Oracle Cloud Infrastructure Kubernetes Engine）においてそれぞれのマネージドサービスに差異があり、マルチクラウドを管理運用する側としては悪夢のような状況だったことを説明。

GCP、AWS、OracleのマネージドKubernetesを使い分ける難しさ

特にこの時点ではOracleのサービスにおいてはOIDCに対応しておらず、フロントエンドはGCPとAWSに限定せざるを得なかったことを説明した。

OIDCでアクセス管理を抽象化できるソリューションを探していた

オンプレミスのKeycloak実装をそのままマルチクラウドに移行できるソリューションを探していたが、オープンソースコミュニティとしては見つからず、KubernetesのIDアクセス管理（IAM）の中にUser Impersonationという機能を発見したことが大きな前進となったことを説明。ここではEnvoyをリバースプロキシとして使い、EKS、AKEに対するアクセスを統一する自家製のサーバーをGoで開発したことを説明した。Kubernetesの操作に対する特権についてbind、escalate、impersonateというパラメーターが用意されていることでアクセスを許可可能とするという部分が、TikTokがやりたかったことに対して使えるということだろう。

KeycloakからのアクセスをEnvoyに中継する認証サーバーを開発

これによってユーザーは通常のkubectlコマンドをそのまま使い、ユーザー認証の後にリバースプロキシがプラットフォームごとに必要な要素を追加し、コマンドをターゲットとなるクラスターにフォワードすることで構成の変更が可能になることを説明した。

ユーザーからのコマンドが処理される流れを解説

リバースプロキシについてはより詳細な説明を行い、Listener、Router、HTTP Filterなどの機能が用意されていることを解説した。

リバースプロキシの概念図

ここではRouterの例、HTTPフィルターの例などを使って解説した。ユーザーが実行したいkubectlコマンドをターゲットになるプロバイダーごとに調整して書き換えるのが目的だ。

Routerの例

HTTP Filterの例

またAuthorization Serverについても解説を行った。

Authorization Serverの機能を解説

Mogulla氏はKubernetesの基本機能をそのまま使いながら、TikTokが必要としていた複数のマネージドサービスをユーザーに意識させることなく抽象化させる機能をGoで自社開発したサーバーについて解説を行った。ここで解説は終わったが、興味深いのは質疑応答の中で「ここで説明された機能は自社開発しなくてもTeleportというオープンソースプロジェクトを使えば実装できるのは知っている？」と尋ねたエンジニアがいたことだろう。

そのエンジニアがTeleportの社員なのか、Teleportのユーザーなのか、はたまた単に知識としてTeleportを知っていたのかは現地では確認できなかったが、Mogulla氏がやりたいことをどうやって実装すれば良いのかを検討していた段階ではTeleportについては知らなかったのは確実だろう。この質問がなければ、多くの参加者はTikTokのように自社開発するしか方法がないと思ってしまったかもしれない。

●Teleport公式ページ：https://goteleport.com/

オープンソースのTeleportはエンタープライズ向けのプロダクトを用意しているようだ。TikTokが実際にやりたかったことが、Teleportによって実現できるのかどうかは確認が必要だろうが、同じ悩みを抱えている企業にとってはリサーチの対象となるのは確実だろう。質問の形をとった売り込みとも取れるやり取りだったが、セッションの参加者にとっては有意義な質疑応答であったと思われる。