本セッションの登壇者
セッション動画
「個人的、Kubernetesの最新注目機能」ということでお話しさせていただきます。今日は15分という限られた時間なので4つのKEPを持ってきました。どちらかというとクラスタをオンプレで運用している方向けの機能紹介が多いかなと思います。
自己紹介です。須田 一輝（すだ かずき）と申します。XとGitHubでは@superbrothersというIDでやっています。株式会社 Preferred Networksでエンジニアをしていて、社内向けの機械学習プラットフォームと、その知見をクラウドサービスとして提供する社外向けの機械学習のプラットフォームの開発と運用をやっています。あとは、Kubernetes Meetup Tokyoの共同主催もやっています。
SPDYをWebSocketに置き換え、認証まわりの構造化
では早速、紹介していきたいと思います。1つ目は、「KEP-4006 Transition from SPDY to WebsSockets」です。こちらは、Kubernetesコントローラーの exec/attach/port-forward の通信プロトコル、ファイルをコピーするkubectl cp もそうですが、APIサーバーとの送受信プロトコルがSPDY 3.1からWebSocketsに移行するというKEPです。SPDYはすでに2015年ぐらいから非推奨になっていて、現在、多くのL7プロキシやゲートウェイ、ロードバランサがSPDYをサポートしていないとこのあたりのコマンドがうまく動かないという問題がありました。
SPDYはもともとGoogleが開発したプロトコルで、HTTP/2のベースになっています。たとえば、AWS ALBはSPDYをサポートしていないので、クライアントとAPIサーバーの間のロードバランサにはALBが使えないという問題もありました。ちなみに、L4なら問題ありません。先月リリースされた最新のv1.30で、クライアント（kubectl）からAPIサーバーの間の通信をWebSocketでトンネリングしてWebSocketに置き換える変更が入りました。WebSocketであればだいたいのロードバランサがサポートしているので、AWS ALBも使えるのではないかと思います。ただ実際にはAPIサーバーとKubelets間にもSPDYが使われているのですが、利用者としてはクライアントとAPIサーバーのところが主な問題です。「kubectlとAPIサーバーの間になぜL7のロードバランサを使いたいんだっけ」ということですが、そのモチベーションは、KEPには書かれていません。推測すると、APIサーバーの脆弱性などで認証機能がうまくきかないなどの問題があった場合にその前段で検証するというニーズがあるのかなとは思っています。
このKEPは「SPDYを完全に廃止する」ということが最終目標になっています。ただ、だいたいのユーザーの問題点はクライアントとAPIサーバーの間だけで、それ以降のところもKEPとしては置き換えるというところで進んではいますがあまり大きな問題にはなっていないので、徐々に進んでいくことになると思います。GAが1.31ということで、もうベータで一部使い始められるようになっています。
次が「Structure Authentication Config」というKEPです。構造化された認証設定みたいなもので、ベータのターゲットが1.30です。これも先月リリースされていて、もう使えるようになっています。GAのターゲットはまだ機能が完全に実装されていないため、1.34です。設定ファイルで認証設定が書けるなど、嬉しい機能がいろいろと新しく追加されています。
まず1つ目が、複数のOpen ID Connector（OIDC）プロバイダが使えることです。右側が実際の設定ファイルで、jwtの下が配列になっていて、複数書けます。これまでKubernetesではOIDCプロバイダを1つしか扱えなかったので、複数使おうとするとKubernetesの外で多重化するDexなどのプロバイダを選択して使う必要がありました。
次が動的な設定で、設定ファイルを更新したら、APIサーバーの再起動なしに設定を自動で反映できます。APIサーバーを再起動すると、execなどを使っている場合にコネクションが切れたりするので、なるべく再起動しなくて済むのはいいと思います。
JWTクレームの検証もできるようになります。設定ファイルのclaimValicdationRulesで、特定のグループに属していないなどrequiredValueでルールを指定して認証を失敗させることができます。これまでは認証できていればAPIリクエストができたので、使わせたくない場合にはAPIサーバーで認可しないようにするしかなかったのが、認証を細かく制御できるようになりました。
4つ目が任意のクレームのユーザー特性へのマッピング。たとえばクレームにユーザー名やグループを割り当てられるようになります。割り当てた値の前にプレフィックスを付けられる便利機能も入っています。
最後が複数のaudiencesのサポートです。サンプルのaudiencesが配列になっているところからも分かると思います。kubectlとダッシュボードでaudiencesを使い分ける場合に複数使えます。用途としては、たとえば、ユーザーとクラスタの管理者でOIDCプロバイダを分ける使い方がありますし、異なる複数の認証でOIDSプロバイダを使い分けることもできるようになります。この辺は順当ないい感じの機能拡張だと思います。
ユーザーネーム空間でセキュリティ向上、Webhookサーバー構築低減も
次は「Support User Namespaces」という若い番号のKEPです。ベータのターゲットが1.30でこれも最新のバージョンで使えるようになっています。GAターゲットは未設定です。
内容は、Podをこれまでよりも安全にrootで実行できるようになるというものです。基本的にPodをそもそもrootで実行しないのがKubernetesのベストプラクティスではありますが、rootを渡したいこともあります。作りとしてはノード（実際のホスト）で見るとPod内のrootが非特権ユーザーにマッピングされている状況にすることで、コンテナの中で安全にrootが使用できるというものです。また、Pod内でのみ有効なLinuxの Capabilities を付与できるので、たとえば FUSE ファイルシステムのマウントにはCAP_SYS_ADMINが必要ですが、これも安全に渡すことができます。
一番大きいのは、セキュリティ強化です。将来的に未知のコンテナランタイムの脆弱性やカーネルの脆弱性が出てきた時に、ホストに入られると特権ユーザーだと何でもできてしまいますが、非特権ユーザーになっていれば、できることが限定されます。
使い方としては、右上のようにhostUsers をfalseにします。デフォルトはtrueです。具体的な仕組みは、たとえばホストで直接プロセスを立ち上げる時にはUIDの0から65535までを使う、それ以降のUIDとGIDはコンテナで使うように予約しておいて、たとえばPodでhostUsersをfalseで立ち上げると、コンテナの中はUID: 0で立ち上がるけれどもホストから見た時には65536として扱われます。これによってホストに侵入された場合にもrootではないので安全だという仕組みになっています。ただ、使用する際には条件があって、Linuxカーネル6.3以上と、コンテナランタイムのサポートが必要になります。条件を合わせれば使えるようになるので、気になる方はぜひお試しください。
最後は、「KEP-3962 Mutating Admission Policies」です。アルファターゲットが1.31なので次のバージョンに入ってくるかなというところです。これはCELを使ったリソースのMutatingというもので、Podを作った時にサイドカーコンテナを自動で付けるなどに使うものです。
リソースのValidatingは機能が1.30で「ValidatingAdmissionPolicy」がGAしましたが、Mutating はビルトインではできていなくて、結構手間がかかっていました。ちょっとした Mutating の操作をするためにはWebhookサーバーを自分で書く必要がありますが、Webhookサーバーは運用しないといけなくて、パフォーマンスも悪いので、あまりやりたくないですよね。このKEPでKubernetesがAPIサーバーの中で実行してくれるようになるので、Webhookサーバーの運用なしで使えてよいと思います。条件分岐が激しいものの対応は難しいですが、大部分は十分足りると思うので、パッと見もシンプルでテストも不要なものはこれを使って、条件が厳しくてテストコードも必要なMutatingの場合はGoでWebhookサーバーを書くなど、使い分けるのがよいと思います。
今日は以上4点を紹介させていただきました。
最後ですが、株式会社 Preferred Networks のクラスタチームでは、機械学習プラットフォームエンジニアとしてメンバーの募集をしておりますので、Kubernetesで機械学習のプラットフォームを作ってみたい方はぜひ一読いただけると嬉しいです。カジュアル面談もあります。
以上になります。ありがとうございました。
