fbpx

CL LAB

HOME > CL LAB > AquaSecurity > Kubernetesバージョン1.24について知っておきたいこと #aqua #コンテナ #セキュリティ #k8s

Kubernetesバージョン1.24について知っておきたいこと #aqua #コンテナ #セキュリティ #k8s

 ★ 1

本ブログは「Aqua Security」社の技術ブログで2022年4月25日に公開された「 What’s New in Kubernetes Version 1.24 」の日本語翻訳です。

Kubernetesバージョン1.24について知っておきたいこと


Kubernetes の新たなリリースを目前に控え、これまで同様、検討すべき新機能が目白押しです。その中には、企業が Windows コンテナを安全に使用するための機能や、Kubernetes のサプライチェーンセキュリティの改善も含まれています。この記事では、このリリースのいくつかの重要な機能を見ていきます。

Dockershim 廃止

今回の Kubernetes のリリースで最も大きな変更点は、間違いなく Dockershim が削除されたことです。これは、コンテナランタイムとして Docker を直接サポートするもので、コンテナランタイムインターフェース(CRI)が標準化される前に必要とされたものです。

この削除は、コンテナランタイムとして Docker を使用しているクラスターに影響を与えますが、Containerd や CRI-O など、他の一般的な CRI を使用しているクラスターには影響を与えません。なお、3大マネージド Kubernetes ディストリビューションである GKE、AKS、EKS は、以前から新しいクラスターに Containerd を使用しているため、今回の影響は古いクラスターのみになると思われます。

この影響を受けるクラスターには、いくつか対応の選択肢があります。1つは Mirantis の CRI-Dockerd を使うことです。これは Docker が Docker Desktop 製品で行っていることと同じです。もう1つの選択肢は、利用可能な代替 CRI オプションの1つにクラスターを移行することです。

Kubernetes プロジェクトは、このトピックに関する詳細な情報をドキュメントページで公開しています。

Kubernetesアーティファクトの署名

Kubernetes のアーティファクトを Kubernetes プロジェクトのリポジトリから直接ダウンロードする企業にとって有益な変更点は、1.24 からアーティファクトが Cosign署名され、ユーザがその完全性と信憑性を検証できるようになることです。デジタル署名のようなセキュリティプロセスが効果的で信頼できるものであるためには、それが十分に普及する必要があります。使用するソフトウェアの 5% だけを検証するだけではあまり意味がないので、Kubernetes プロジェクトがこの機能を追加するのは素晴らしいことです。

SecretベースのServiceAccountTokenの削減

ServiceAccountToken のセキュリティを向上させる動きの一環として、Secret ベースの ServiceAccountToken の削減が 1.24 でベータ版に移行しています。従来、Kubernetes では、これらのクレデンシャルには有効期限が設定されていないため、ServiceAccount の存続期間中は有効なままとなります。これは、高い特権のある ServiceAccountToken にアクセスした攻撃者が、それを使ってクラスターへのアクセスを持続させることができるため、クラスターにセキュリティリスクをもたらす可能性があります。

Kubernetes は短命な Token を持つより良いシステムに移行しつつあり、この機能によって古い Secret ベースのシステムの削除が進むでしょう。

API Admission による Windows Pod の識別

API Admission レベルで Windows Pod を識別することは、Windows コンテナを利用するクラスター運用者にとって便利な機能です。基本的には、コンテナのOSが Admission Controller であると認識させることで、使用されているOSに応じて異なるセキュリティポリシーを適用できます。Linux と Windows は異なる SecurityContext 設定をサポートしているため、これは重要なことです。この変更により、クラスターに対してより良いセキュリティポリシーを作成できます。

ベータ版の機能はデフォルトでオフ

これはコードの変更ではありませんが、今後の Kubernetes のリリースで新機能がロールアウトされる方法に影響します。これまで Kubernetes のポリシーとして、アルファ版の機能はデフォルトで無効、ベータ版の機能はデフォルトで有効となっていました。そのため、リリースに至る前に API が変更される可能性のある機能が多く利用されていました。

新機能のフィードバックを早期に得ることは有用ですが、このアプローチでは安定性と複雑性に問題をもたらす可能性があります。このような背景から、今後のリリースでは、ベータ版に当たる機能はデフォルトで無効化されることが決定されました。マネージドでない Kubernetes クラスターでは、管理者は Kubernetes API サーバにフラグを渡すことでベータ機能を有効にできます。しかし、マネージドディストリビューションでは、どのベータ機能を有効にするかは、プロバイダ次第となります。

まとめ


この Kubernetes の最新リリースでは、本番環境に問題を引き起こさないようにシームレスにアップグレードするためにも、特に Dockershim などの慎重な調査を必要とする変更が、いくつかもたらされました。また、Kubernetes のデフォルトのセキュリティ状態の改善について継続的な進展が見られ、新しいクラスターが管理者とユーザにとってより安全な見通しとなることは喜ばしいことです。

New call-to-action

CL LAB Mail Magazine

CL LABの情報を逃さずチェックしよう!

メールアドレスを登録すると記事が投稿されるとメールで通知します。

メールアドレス: 登録

※登録後メールに記載しているリンクをクリックして認証してください。

Related post

DXウェビナーシリーズ第1弾_GitLab編