本日は、マネージドセキュリティ・サービス・プロバイダーのKudelski Security社の友人によって書かれたブログ記事を公開します。数週間前、Kudelski Security社の主席クラウドおよびセキュリティエンジニアであるRomain Aviolat氏は、リモートワーク環境における安全なアプリケーションアクセスを保証するために、Cloudflare Tunnelと呼ぶCloudflareのID認識プロキシを利用した難題に対する独自のソリューションを当社のZero Trustチームに持ちかけてきました。
私たちは、彼らのソリューションについてとても楽しく学ぶことができたので、彼らの話をもっと広めたいと思いました。特に、Kudelski Security社のエンジニアが、当社の技術の柔軟性と拡張性をフルに活用し、エンドユーザーのワークフローを自動化したことを高く評価しています。Kudelski Security社についてもっと知りたい方は、以下の作品や同社のリサーチブログをご覧ください。
KubernetesへのZero Trustアクセス
ここ数年、Kudelski Security社のエンジニアリングチームは、当社のインフラストラクチャをマルチクラウド環境に移行することを優先してきました。社内のクラウド移行は、エンドユーザーが追求しているものを反映しており、彼らのためにサービスを強化するための専門知識とツールを備えています。さらに、この移行は、私たち自身のセキュリティアプローチを再考し、Zero Trustのベストプラクティスを取り入れる機会にもなっています。
これまで、Zero Trustの採用で最も困難だったことの1つは、複数のクラウド環境にわたるさまざまなKubernetes（K8s）コントロールプレーン（API）へのアクセスを確保することでした。当初、当社のインフラストラクチャチームは、さまざまなK8sクラスタに関連するさまざまなAPIを可視化し、一貫したIDベースの制御を適用するのに苦労しました。さらに、これらのAPIを操作する際、開発者はどのクラスタにどのようにアクセスする必要があるのかがわからないまま放置されることがよくありました。
こうした摩擦に対処するため、私たちはCloudflareを活用した自社ソリューションを設計し、開発者がパブリッククラウドやオンプレミス環境にあるK8sクラスタに対して安全に認証を行う方法を自動化しました。具体的には、ある開発者があるクラウド環境でアクセスできるすべてのK8sサービスを表示し、CloudflareのZero Trustルールを使ってアクセス要求を認証し、CloudflareのID対応プロキシCloudflare Tunnelを使ってそのクラスタへの接続を確立することができるようにしました。
最も重要なことは、この自動化ツールによって、Kudelski Security社は組織としてセキュリティ体制を強化し、同時に開発者の体験を向上させることができたことです。このツールによって、新しい開発者がドキュメントを読んだり、ITサービスチケットを提出したり、さまざまなK8sクラスタにアクセスするために必要なさまざまなツールを手動で導入・設定する時間を、少なくとも2時間短縮することができると見積もっています。
このブログでは、私たちが取り組んだ具体的なペインポイント、自動化ツールの設計方法、そして在宅勤務に適した方法でCloudflareが私たちのZero Trustジャーニーの進展にどのように貢献したかについて詳しく説明します。
マルチクラウド環境におけるセキュリティの課題
Kudelski Security社が顧客サービスや社内開発チームを拡大するにつれ、複数のK8sクラスタや複数のクラウドプロバイダ内のアプリケーションのフットプリントも本質的に拡大してきました。当社のインフラエンジニアや開発者にとって、K8sクラスタAPIはトラブルシューティングのための重要なエントリーポイントとなっています。私たちは GitOps で作業しており、すべてのアプリケーションのデプロイは自動化されていますが、それでも頻繁にクラスタに接続してログを取得したり、問題をデバッグしたりする必要があります。
しかし、この多様性を維持することは、インフラ管理者に複雑さとプレッシャーを与えることになります。エンドユーザーにとっては、インフラストラクチャが広大になると、クラスタごとに異なる認証情報、異なるアクセスツール、および異なる設定ファイルを追跡することになります。
このような複雑なアクセス環境は、リアルタイムのトラブルシューティングを特に困難なものにしています。例えば、オンコールで待機しているエンジニアが、慣れないK8s環境を理解しようとすると、難しいドキュメントを調べたり、簡単な質問をするために他の同僚を起こさなければならなくなることがあります。このようなことは、ミスを招きやすく、貴重な時間を浪費することになります。
K8sのAPIへのアクセスを保護するための一般的で伝統的なアプローチは、私たちが避けたいと思う課題を示していました。例えば、APIを公共のインターネットに公開することは、本質的に攻撃対象領域を増やすことになり、それは私たちに許されないリスクだと感じていました。さらに、内部ネットワーク経由でクラスタのAPIに広くアクセスできるようにし、横方向の移動のリスクを許容することはしたくありませんでした。Kudelski社が成長し続けるにつれ、従業員やさまざまなクラウド環境にVPNを導入するための運用コストや複雑さは、スケーリングの課題にもつながっていくことでしょう。
その代わりに、小規模でマイクロセグメント化された環境、小さな障害ドメイン、サービスへのアクセス方法を複数にしないことを維持できるようなアプローチを求めました。
CloudflareのIdentity-aware Proxyを活用したZero Trustなアクセス。
Kudelski Security社のエンジニアリングチームは、IAP（Identity-aware Proxy）を介してユーザーと各K8クラスターを接続するという、より現代的なアプローチを選択しました。IAPは柔軟に導入でき、アクセス要求があったときにユーザーの身元を確認することで、アプリケーションの前にさらなるセキュリティレイヤーを追加することができます。さらに、ネットワーク全体ではなく、ユーザーから個々のアプリケーションへの接続を作成することで、当社のZero Trustアプローチをサポートしています。
各クラスタには独自のIAPとポリシーのセットがあり、ID（企業のSSO経由）と、開発者のラップトップのデバイス姿勢のような他のコンテキスト要因をチェックします。IAP は K8s クラスタの認証メカニズムを置き換えるのではなく、その上に新しいメカニズムを追加するもので、ID フェデレーションと SSO のおかげで、このプロセスはエンドユーザーにとって完全に透過的です。
Kudelski Security社は、Cloudflare AccessのコンポーネントとしてCloudflareのIAPを使用しています。これはZTNAソリューションであり、CloudflareのZero Trustプラットフォームによって統合されたいくつかのセキュリティサービスの1つです。
多くのWebベースのアプリケーションでは、IAPはブラウザ経由でアクセスを要求するエンドユーザーにとって摩擦のないエクスペリエンスを実現するのに役立っています。ユーザーは、保護されたアプリにアクセスする前に、企業のSSOまたはIDプロバイダーを介して認証を受けますが、IAPはバックグラウンドで機能します。
CLIベースのアプリケーションでは、ブラウザで行うようなCLIネットワークフローのリダイレクトができないため、そのユーザーフローは異なるように見えます。私たちの場合、エンジニアは kubectlまたはk9sのようなCLIベースのお気に入りのK8sクライアントを使いたいと考えています。つまり、Cloudflare IAPはCLIクライアントと各K8sクラスタとの間でSOCKS5プロキシとして動作する必要があります。
このIAP接続を作成するために、Cloudflareは、_cloudflared_という軽量なサーバーサイドのデーモンを提供し、インフラとアプリケーションを接続しています。この暗号化された接続は、Cloudflareのグローバルネットワーク上で実行され、シングルパス検査でZero Trustポリシーが適用されます。
しかし、自動化がなければ、Kudelski Security社のインフラチームは、エンドユーザーのデバイスにデーモンを配布し、それらの暗号化接続の設定方法を指導し、その他の手動、手作業による設定手順を踏み、長期的に維持する必要があります。さらに、開発者は通常の業務でアクセスする必要がある、異なるK8sクラスタ間の可視性を確保するための単一ペインがないままです。
自動化ソリューション：k8s-tunnels!
これらの課題を解決するために、当社のインフラエンジニアチームは、開発者の生活を楽にする複雑な設定手順を組み込んだ「k8s-tunnels」と呼ばれる内部ツールを開発しました。さらに、このツールは、作成されたZero Trustポリシーに基づいて、特定のユーザーがアクセスできるすべてのK8sクラスタを自動的に検出します。この機能を実現するために、Kudelski Security社が利用しているいくつかの主要なパブリッククラウドプロバイダーのSDKを組み込みました。また、このツールには、cloudflared daemon が組み込まれています。つまり、ユーザーに配布するのは1つのツールだけでよいということです。
このツールを起動した開発者は、次のようなワークフローを経ることになります（ユーザーはすでに有効な認証情報を持っていると仮定しています。そうでないと、認証情報を取得するためにIDP上でブラウザが開いてしまいます）
1. ユーザーは、1つまたは複数のクラスターを選択します。
2. k8s-tunnelは自動的にCloudflareとの接続を開き、開発者マシンのローカルSOCKS5プロキシを公開します。
3. k8s-tunnelは、ローカルのSOCKS5プロキシを経由するために必要な情報をプッシュすることで、ユーザーのローカルkubernetesクライアント設定を修正します。
4. k8s-tunnelは、Kubernetesクライアントのコンテキストを現在の接続に切り替えます。
5. これで、ユーザーは自分の好きなCLIクライアントを使って、K8sクラスタにアクセスできるようになります。
このプロセスは実に簡単で、当社のエンジニアリングチームが日常的に使用しています。そしてもちろん、この魔法はk8s-tunnelsに組み込まれた自動検出メカニズムによって実現されているのです。新しいエンジニアがチームに加わるたびに、自動検出プロセスを起動するように指示するだけで、すぐに始められます。
ここでは、オートディスカバリープロセスの動作例を紹介します。
k8s-tunnelsでは、私たちのさまざまなクラウドプロバイダーのAPIに接続し、ユーザーがアクセスできるK8sクラスタをリストアップします。
k8s-tunnelsはこれらのクラスタのユーザマシン上にローカル設定ファイルを保持するため、このプロセスが複数回実行されることはありません。
オートメーションの強化
オンプレミスの場合、パブリッククラウドプロバイダーのリソースタグのように、K8sクラスタのメタデータを保存する簡単な方法がなかったため、少し厄介なことになりました。 VaultをKey-Value-storeとして使用し、オンプレミス用のパブリッククラウドリソースタグを模倣することにしました。こうすることで、パブリッククラウドプロバイダーと同じプロセスでオンプレミスクラスタの自動検出を実現することができます。
先ほどのCLIのスクリーンショットで、ユーザーが複数のクラスタを同時に選択できることをご覧になった方もいらっしゃるかもしれません。私たちはすぐに、開発者が本番環境とステージング環境で実行されているワークロードを比較するために、同時に複数の環境にアクセスする必要があることが多いことに気づきました。そこで、クラスタを切り替えるたびにトンネルを開いたり閉じたりする代わりに、単一のk8s-tunnelsインスタンス内で複数のトンネルを並行して開き、ラップトップ上で接続先のK8sクラスタを切り替えるだけでよいようにツールを設計しました。
最後になりましたが、Cloudflare Workersを活用して、お気に入りや新着リリースの通知に対応しましたが、これはまた別のブログ記事で紹介します。
次は何を？
このツールを設計する際に、SOCKS5プロキシと組み合わせて使用した場合のKubernetesクライアントライブラリ内部のいくつかの問題を特定しました。私たちは Kubernetesコミュニティと協力して、これらの問題を修正しています。近い将来、誰もがこれらのパッチから恩恵を受けるはずです。
今回のブログでは、マルチクラウド環境上で稼働する複雑なワークロードに対してZero Trustセキュリティを適用し、同時にエンドユーザーエクスペリエンスを向上させることが可能であることを強調したいと思います。
今日、私たちの「k8s-tunnels」コードはKudelski Security社に特化しすぎていますが、私たちの目標は、私たちが作ったものをKubernetesコミュニティに還元し、他の組織やCloudflareの顧客がその恩恵を受けられるようにすることです。