KubernetesのIPアドレスのホワイトリスト登録：私たちが学んだこと

Linode システムエンジニアの Jon "jfred" Frederickson が、Linode 上で Kubernetesを実行するためのIPホワイトリスト機能を構築する彼の経験を共有します。

Linode エンジニアリングチーム が Kubernetesの機能構築を行なった際、予想通り多くの障害に遭遇しました。しかし、私たちが予想していなかった課題が一つ起こリました：私たちのインフラでKubernetesで実行されているアプリケーションをどのようにホワイトリストに入れるか、である。

ここ Linode では、複数の内部アプリケーションを実行しています。ファイアウォール規則を使用する事で、これらのアプリは、それを必要とするネットワークとシステムのみがアクセスできます。

独自のデータベースを持つアプリケーションがある場合、そのデータベースにアクセスする必要があるのは、おそらくそのアプリケーションのインスタンスだけです。双方が Kubernetes クラスターで実行されている場合は簡単です。ネットワーク ポリシーを使用するとそれをロックダウンできます。一方、どちらかのサービスがクラスターの外部で実行されている場合、事態はより複雑になります。

すでにIPホワイトリストに関する自動化は存在していましたが、Kubernetesクラスターは当社のインフラのこれまでのなによりのもダイナミックになる可能性を秘めています。 そのため、ノードがクラスターに追加またはクラスターから削除された場合に、ホワイトリストを常に最新の状態に保つ必要がありました。これはKubernetesをどのインフラに導入する人にとっても一般的な問題であると考えましたが、その問題に対する公な解決策は見つけられませんでした。

課題

課題：クラスタの外部にあるサーバ上の特定のクラスタ内のすべてのノードをホワイトリストに登録する場合、理想的な設定はどのようなものになるでしょうか？

Kubernetes 対応ツールがなければ、クラスタ ノードの個々の IP アドレスを手動で 1 つずつホワイトリストに登録する必要があります。これには時間がかかるだけでなく、人為的ミスの可能性が高まり、開発プロセスの大きなハードルとなっています。

ソリューション

数週間をかけて、私は手動で単一のIPをホワイトリストに登録するのと（ほぼ）同じくらい簡単にKubernetesクラスターをリストに入れるソリューションを構築しました。

私たちは Salt を使って私たちのインフラ管理を行います。ファイアウォール ルールを管理するための Salt 策が既に用意されています。Salt に登録されているインフラの中に、ホワイトリストを構築する際に特定のクラスのシステムを見つけるメカニズムがすでにあったので、Kubernetesクラスター用に似たものを探していました。

Salt は非常にフレキシブルで、カスタムモジュールの作成が簡単です。たとえば我々のiptables 公式はソルトのノードごとの構成 ("pillar" データ) から iptables ルールを生成します。これを行うには、柱に格納されているルールのリストから1 つのルールずつ構築していきます。それは確かに少し醜く見える大量の文字列の連結です。幸いなことにiptables ルールのフォーマットはは安定していて結果的にはかなりうまく動作しています。どのように見えるか、スニペットを示します。

KubernetesのフレキシブルなAPIのおかげで、この統合は概念的にはそれほど難しくありませんでした。基本的にはK8s クラスターの新しいルールタイプを追加しました：数式がそのタイプのルールを検出すると、そのクラスターにアクセスしてノードの IP をフェッチし、ローカルにキャッシュし、各 IP用に iptable ルールを挿入します。キャッシュ化は、断続的なネットワーク障害が問題を引き起こさないことを保証するためです。使用方法は次のとおりです。

次のステップ

最終的には、ツールの能力をさらに向上させる為にための公式ををオープンソースにして Linode コミュニティの協力を得たいと考えています。

しかし、次のステップは、新しいノードがクラスタに参加したり退出したりするとこれらのルールが自動的に更新されるようにすることです。目標はクラスタを 永続的にホワイトリスト化することで、単一のIPをホワイトリスト化するのと同じくらい簡単なものにすることですが、まだそこまでには至っていません。

公式は現在、ファイアウォール構成が適用された場合にのみ新しいノードを選択しますが、自動的には選択されません。ファイアウォール構成を定期的に再適用することで回避できるため、これはあまり問題ではありません。

しかし、私はそれをより応答性が良くなる方法を考え出したいと思います。私の想定するメカニズムは、そのイベント(Kubernetesでの新しいNodeオブジェクトの作成)を見張り、更新を(おそらくSaltイベントバスを介して)トリガーします。理想的には、Kubernetes ファイアウォールルールの設定以外に手動の手順は必要なくなります。私たちが式をオープンソース化したら、みなさんがそれを実現する方法を探すのを手伝ってくれるでしょう!

今のところ、私は作成したものに本当に満足しており、それがKubernetes を試している Linode ユーザーにとって資産になると信じています。

Linode のシステムエンジニアリングプロセスについてまんんでくれてありがとうございます。私たちが行なったことにについて質問がある場合は、コメント欄で私に知らせてください。

Linode上の Kubernetes 興味がありますか ?

当社のチームは、コンテナ化されたアプリケーションとワークロードをデプロイして管理するための完全に管理されたコンテナオーケストレーションエンジンであるKubernetes Engine (LKE)のベータ版を紹介できることに誇りに思っています。

ただし、皆様のフィードバックを必要としています。ここからLKEベータ版にサインアップして試してみて、無料のLinodeスワッグをゲットしてください。