2021.06.24

Kubernetesのセキュリティを向上：クラスターをアップグレードして漏洩を防ぐ #aqua #コンテナ #セキュリティ #Kubernetes #k8s

145

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは「Aqua Security」社の技術ブログで2021年6月10日に公開された「 Improving Your K8s Security: Upgrade Your Clusters and Avoid Exposure 」の日本語翻訳です。

Kubernetesのセキュリティを向上：クラスターをアップグレードして漏洩を防ぐ

クラウドネイティブ開発への移行に伴い、サービスがインターネット上に公開され、攻撃者に容易に発見されるリスクは高まる可能性があります。また、Kubernetes のバージョン変更のペースが速いことも相まって、脆弱性が原因でセキュリティ事故が発生する危険性もあります。最近インターネット上に公開されている Kubernetes システムの調査を行い、いくつかの潜在的な懸念事項を明らかにしました。

Kubernetesのインターネットへの公開

私が Kubernetes のシステムを調査した最初の目的は、インターネットに直接公開されているクラスターがどれだけあるかを調べることでした。私が行った検索では 750,000 以上のシステムが見えましたが、これらは Kubernetes の API サーバと思われます。

Kubernetes システムは、API サーバの TLS 証明書の設定方法に既知の文字列が含まれているため、インターネット上では比較的容易に特定できますが、/version という API エンドポイントへの未認証アクセスによっても特定できます。このエンドポイントは、オンプレミスのクラスターでは認証なしで利用できるようになっていることが多く、それはインターネットから確認できます。確認した結果、9万以上のクラスターでクエリーが可能になっていました。

このことから、攻撃者は比較的容易に標的となるクラスターを特定でき、多くの場合使用されているバージョンも特定できます。その結果、このクラスターにどの脆弱性が含まれるか、CVE から特定できるでしょう。

ここで、企業が最初に検討すべきアドバイスとしては、Kubernetes API サーバがインターネットから直接アクセスできる必要が本当にあるのかということです。VPN や踏み台サーバの後ろに置いたり、送信元 IP アドレスの範囲を制限したりすることで、インターネット上で攻撃対象のクラスターを探している攻撃者が、あなたのサービスを見つけられなくなります。

公開されたクラスターのアップグレードの重要性

もちろん、API サーバを利用できるようにする必要があるユースケースもあるでしょうし、そのような場合には、Kubernetes のバージョンを更新して CVE に対処することが不可欠です。また、クラスターがディストリビューションのサポートライフサイクルの範囲内にあることを確認することも、非常に重要です。そうしないと、新しいパッチがリリースされても、古いバージョンを使用したクラスターではパッチを利用できないため、急いで新しいメジャーバージョンへアップグレードしなければならなくなります。

インターネット上で確認できたクラスターのバージョンのデータを見ると、これがクラスタ運用者にとっての課題であることがわかります。バージョン番号が表示されていたクラスターの 26% は、サポートされていない可能性の高い Kubernetes のバージョンを実行していました。

ここで考慮すべき重要な点は、これが当てはまるのは自己管理のクラスターだけではないということです。実際、インターネット上で見ることができるサポートされていないバージョンの大半は、AWS EKS クラスターのようでした。マネージド Kubernetes クラスターでは、コントロールプレーンを日常的に管理する必要性はありませんが、アップグレードを計画し実行することは、ユーザ側の責任となります。

クラウドプロバイダーのドキュメントによると、クラウドプロバイダーはサポート終了後のある時点で自動的にクラスターをアップグレードすることになっているので、タイミングよく更新することも重要です。バージョンによっては、Kubernetes のアップグレードには破壊的な変更を含むことがあるため、クラスターのワークロードに可用性の問題が発生する可能性があります。特に 1.16 へのアップグレードでは、いくつか非推奨の API が削除され、非推奨のエンドポイントをターゲットにしたワークロードは破損することになります。

まとめ

今回の調査では、いくつかの重要なポイントがあります。

必要のない情報を公開しないことで、セキュリティを向上：
ほとんどのマネージド Kubernetes ディストリビューションでは、コントロールプレーンをプライベートネットワークまたは特定の CIDR 範囲でのみ利用できるようにしています。この制御を追加することで、攻撃リスクを減らすことができます。
すべての Kubernetes クラスターのアップグレードサイクルを計画することの重要性を理解：
理想的には、3ヶ月ごとにクラスタのアップグレードを行い、利用可能な新バージョンを活用することです。これにより、(多段アップグレードではなく)単一のバージョンのみのアップグレードを行うことができ、リスクを軽減できます。また、クラスターを管理するチームは、アップグレードプロセスを定期的に練習できます。3ヶ月サイクルが現実的ではない企業の場合、使用中のバージョンが引き続きセキュリティアップグレードを受けていることを保証するために、最低でも9～12ヶ月ごとにアップグレードを行う必要があります。マネージド Kubernetes プロバイダーの中には、もう少し長いサイクルを許可しているところもありますが、「長期サポート」オプションを提供しているところはまだありません。
クラウドプロバイダーの責任共有モデルを理解：
クラスター運用のどの領域までが責任範囲なのか理解しましょう。今回のケースでは、クラスター管理者の中には、クラウドプロバイダーがアップグレードを担当してくれるものと思い込んで運用している人がいるのではないかと予想しています。しかし、これまで見てきたように、そうではない場合もあります。