LINEヤフー Advent Calendar 2023の13日目の記事です。
こんにちは、LINEヤフー株式会社でSREとして働いている岩山です。
今回は出向先の出前館で進めているマルチテナンシーのKubernetes（k8s）クラスタとサービス間通信の認可について、その構築作業の中で得られた知見を紹介します。
いくつか導入したツールの紹介を同じチームの出向組メンバーである岡田・望月・岩山の3名でお送りします。
k8sのマルチテナンシーとは
マルチテナンシーとは「テナント」と呼ばれる複数のチームなどの単位で k8s クラスタを共有することです。
参考： https://kubernetes.io/docs/concepts/security/multi-tenancy/
出前館では数百名の開発者が20個前後のチームを構成し、アプリケーションの開発を行っています。それぞれのチームは複数のコンポーネントを持ち、全体としてマイクロサービスアーキテクチャが構成されています。
リソース管理を効率化するために、全チームの k8s クラスタを統合する際には、各チームが必要以上の権限を保持しないように、それぞれのチームをテナントとした権限制御の仕組みやモニタリングの仕組みが必要です。 出前館SREチームのメンバーのミッションとして、このクラスタの構築を進めています。
マルチテナンシーk8sクラスタのための活用技術例
マルチテナンシーk8sクラスタを実現するために、私のチームが導入した技術とその事例について紹介します。
Hierarchical Namespaces（HNC）
私のチームはマイクロサービスアーキテクチャを採用し、それらのサービスを k8s クラスタ上で運用しています。k8s クラスタではマルチテナンシーを採用し、チームごとに Namespace を作成しています。しかし、権限統制の観点で Namespace の作成が頻繁に行われると、その都度 SRE チームに依頼が来てしまうという課題がありました。そこで、私のチームは Hierarchical Namespace Controller（HNC）を導入しました。
Hierarchical Namespaces（HNC）とは
HNC は、Kubernetes の Namespace を階層的に管理するためのツールです。HNC は、Namespace をツリー構造に整理し、ツリーやそのサブツリーにポリシーを適用することで、以下のような利点を提供します。
-
ポリシーの容易な適用
親 Namespace で定義したリソースが子 Namespace に自動的に継承されます。これにより、Role Binding、 Network Policies、 Limit Ranges などのポリシーの適用が容易になり、設定の重複を避けられます。 -
Namespace の自由な作成
子 Namespace は cluster scoped ではないため、特権を持たないユーザーでも作成が可能です。これにより、自由に Namespace を作成でき、管理者の負担も軽減します。
HNC の導入とその効果
HNC の導入により、親 Namespace は SRE チームが事前に作成し、子 Namespace は開発チームが自由に作成できるようになりました。これにより、SRE チームの負担が軽減しました。
ただし、子 Namespace の命名を自由にする、と管理上のわかりやすさや後述のメトリクスの収集時に問題がありました。そこで、子 Namespace の名前に親 Namespace の名前を接頭辞として追加するように、Admission controller を用いて制約を設けました。
さらに、親 Namespace に Role や RoleBinding を設定すると、これらが子 Namespace に波及し、権限管理が簡単になります。親 Namespace に Hierarchical resource quotas を設定し、子 Namespace のリソースの合計が設定値を超えないように制御できるようにしました。
OpenTelemetry Collectorの導入
OpenTelemeryとは
OpenTelemetry は、クラウドネイティブソフトウェアの監視、トレーシング、分析を可能にするオープンソースのツールセットです。出前館では、モニタリング基盤として New Relic を活用しています。k8sクラスタ上にデプロイされるリソースのモニタリングを行うため、OpenTelemetry が提供している telemetry data の収集ツールである OpenTelemetry（OTel）collector を導入しました。
OTel Collectorの導入とその効果
私のチームのクラスタには大きく分けて
- インフラチームが管理するツールのPod
- 前述のHNCで管理される開発チームのPod
の2種類の Pod があり、New Relic 側で各種メトリクスなどの保存先アカウントを切り替える必要がありました。それを実現するために複数の OTel Collector を k8s クラスタ内に導入し、収集対象を分けています。
この構成で各種アプリケーションのメトリクスを収集し、可視化しています。ResourceQuota やk8sクラスタ上の各種メトリクスなども別途収集し、クラスタの状態が New Relic でわかるようにしています。
まず、各 Namespace ごとに New Relic のアカウントを作成します。それぞれの Namespace に設定された OTel Collectorが対応する New Relic のアカウントにデータを送信するよう設定しています。
そして OTel Collector の config を以下のように設定し、親 Namespace および子 Namespace 内の Pod のメトリクスを収集しました。
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
action: keep
regex: "(<親 namespace 名>)|(<親 namespace 名>.+)"この設定により新たに子 Namespace を開発チームが作成した場合でも、自動的にメトリクスが対応する New Relic のアカウントに送信されるようになりました。OTel Collector自体のメトリクスなどもインフラチームが管理するOTel Collectorで収集し、クラスタ管理に必要なデータをインフラ側のアカウントに集約しています。
※ OTel Collectorを用いたメトリクスデータの収集イメージ
出前館におけるサービス間通信の認可について
サービス間通信に認可機能を導入することで、不正アクセスやそれに伴うデータ漏えいのリスクの軽減が可能です。
特定のサービスだけがアクセスできることで、仮に攻撃者が出前館のシステムに侵入してもアクセスできる情報は限定され、リスクの軽減につながります。
現在の出前館では、k8s 以外にも Amazon EC2 などといった k8s 以外でもサービスが稼働しています。
ここでは、k8s 以外で稼働しているサービスがアクセスしてくることも考慮した認可の実現について記述します。
利用技術
Open Policy Agent
Open Policy Agent（OPA）を使い Policy を定義することでアクセス制御を行っています。
選定理由の一つは、EnvoyFilter で組み込みやすかったことです 。
また、別途 Authorization Server を用意しています。
この Authorization Server に求められる要素としては、次のものがあります。
- 認証に成功したら JSON Web Token（JWT）を発行する
- 認証や JWT を検証するために必要な情報を Web API 経由で利用できる
- 任意の権限を定義でき、 JWT の scope へ含められる
- 可用性を高めるための仕組みが使える（クラスターなどが構築できる）
認可の流れ
していること
していることをポイントだけ紹介します。
- アクセス元サービスは Authorization Server で認証し、得られた JWT を使い Request を投げます。
- EnvoyFilter を利用して通信経路に OPA が挟まるようにします。
- OPA の Policy で Authorization Server から JSON Web Key（JWK）を取得し JWT を検証します。
- OPA では HTTP Request の API が提供されています。
- OPA では JWT を検証するための API が提供されています。
- 出前館では共通の Policy を提供し、部分的に 開発者が Policy を追加できるようしています。
- OPA の Policy は Rego を使い定義します。
- 開発者が Rego を扱うための学習コストがもったいないため、 JSON で Policy を定義できるようにしました。
より具体的な運用（Policy の CI/CD など）については、あらためて記事を書きたいと思います。
おわりに
今回は、出向先の出前館で進めているマルチテナンシーのk8sクラスタとサービス間通信の認可について紹介しました。
本記事がk8sクラスタやマイクロサービスのインフラ基盤の構築を検討している皆様のお役にたてば幸いです。最後までお読みいただきありがとうございました。
また、出前館社内でもテックブログを開設しているので、ぜひご一読ください。