Kubernetes入門(32) インフラやセキュリティ関連も。多様化するKubernetesネイティブな開発ツールに求められる機能

システム開発において、開発者の責務は変化し、守備範囲も広くなってきています。これに伴って開発者が利用するツールに求められる機能に関しても、変化や広がりが見られます。今回は、この辺りについてご紹介しましょう。

「開発者が実施すべき責務」の広がり

早速ですが、従来のエンジニアとKubernetesエンジニアにはどういったギャップがあるかを会話形式で見てみましょう。

従来型エンジニア：開発と言えば、Eclipseを使ってJava開発だね。MavenやGradleは使っているけど、基盤周りはインフラエンジニアに任せているよ。
Kubernetesネイティブエンジニア：業務開発者もコンテナ定義ファイルやk8sのマニフェストを開発者が書く必要があります。Build/Ship/Runそれぞれのフェーズで必要な機能が異なりますね。
従来型エンジニア：セキュリティ観点の開発ガイドラインによるセキュリティを確保するのには限界があるから、セキュリティ要件を担保するのは結局システムテスト工程にならざるを得ないな。
Kubernetesネイティブエンジニア：最近はシフトレフトがやりやすくなってきています。実装する段階からツール活用によるセキュリティチェックが可能です。

このように、開発者がインフラ周りの実装を意識したり、セキュリティに関するツールを活用したりと、従来の開発スタイルが変化してきています。

従来の開発スタイルとKubernetesネイティブな開発スタイルの比較

前節の内容について、従来の開発スタイルとの比較の観点からもう少し踏み込んで理解していきましょう。

まず、従来の開発スタイルはどのようなものだったでしょうか? EclipseでJavaのコーディングをし、Mavenのビルドスクリプトを書き、ホストOS(ローカル)のTomcatやPostgreSQL環境にEclipse経由でデプロイしてデバッグ。10～15年前のWeb3層のオンプレミスの開発環境はこのようなスタイルでした。

一方、Kubernetesネイティブな開発スタイルになると、上記に加えてDockerfileやマニフェストなど、ソフトウエアエンジニアがカバーすべき範囲も広くなります。実際、IaC(Infrastructure as Code)の考え方が進展しつつあり、従来あまりバージョン管理されることが多くなかったインフラの定義についても、gitリポジトリで管理されることが当たり前になってきました。これにより、開発ツールがカバーすべき範囲や責務も広がってきます。

分類	コーディング対象	動作環境	求められるスキルレイヤ(≒ツールがカバーすべきレイヤ)
従来	Javaなどアプリケーション中心(Maven含む)	Tomcat/PostgreSQL	アプリケーションレイヤ
Kubernetesネイティブ	上記に加えてDockerfileやマニフェスト	上記に加えてDocker/k8s	上記に加えて一部インフラレイヤ

そんな中、KustomizeやSkaffold、Telepresence、TrivyといったKubernetesネイティブな開発を支える開発支援ツールが次々と登場してきました。

ただ、「どういった機能をどのツールで賄えば良いかわからない」という方や、「これまでのIDE/開発環境で十分」と高をくくっている方もいらっしゃると思います。セキュリティの視点から言っても、イメージスキャンのようなツールで実装工程の比較的早い段階から検知できることを知らずに、セキュリティリスクを放置してしまっている方もいらっしゃるかもしれません。

そこで今回は、Kubernetesネイティブ開発に求められる開発ツールの機能を体系的に紹介します。ご自身にとって快適な新しい開発環境を作るための参考にしていただければ幸いです。

Kubernetesネイティブな開発ツールに求められる機能

前節までで、開発者の「責務」をご理解いただきました。本節は開発ツールに求められる「機能」にフォーカスを当てていきます。

Kubernetesネイティブな開発ツールに求められる機能はいったい何があるのでしょうか? 開発ツールと言えば、まずはエディタやデバッガなどが挙げられます。加えて、セキュリティの観点の機能として、イメージに含まれる脆弱なソフトウエアのスキャンやマニフェストへの秘匿情報の埋め込みチェックなど、さまざまなものが考えられます。

では、こういった機能を何の軸で理解していけば良いのでしょうか?

ここでは、DevSecOpsの考えに則って以下の構成で紹介します^※。

DevOps：開発から運用まで（セキュリティ除く）
DevSecOps：開発から運用までをセキュリティに特化して紹介

※　セキュリティは固有の要素が強いので、別途紹介する予定です。

DevOps：まるで出世魚?! ソースからデブロイまで。開発～運用のフェーズに応じて求められる機能

ソフトウエアはソースの状態から、Dockerコンテナイメージになり、最終的には本番環境にデプロイされ、まるで出世魚のように形を変えていきます。開発フローについて、Dockerのフェーズを中心に考えてみると、Build/Ship/Runのフェーズに沿って、エディタやデバッガなどの機能が必要になります。

一方、アーキテクチャのレイヤの観点で見ると、k8sクラスタ上にコンテナベースのアプリケーションがデプロイされる構造であるため、「アプリ」「コンテナ」「k8sリソース」のレイヤ別に理解すると良いでしょう。

つまり、以下の表のようにフェーズ（列）とレイヤ（行）の2軸でツールに求められる機能を理解するイメージになります。Devフェーズで言えば、業務プログラムアプリ以外にも、コンテナ定義やマニフェストそれぞれに適した機能が求められる、といった具合です。

	Dev	Build	Ship	Run
求められる代表的な機能	エディタ、静的チェック	ビルド	レジストリ登録	デバッガ
アプリケーション	業務プログラム(Go、Java)	実行ファイル(jar、war)	アーティファクトレジストリ(NEXUS)	WebAPサーバ(nginx、Tomcat)
コンテナ	コンテナ定義(Dockerfile)	Dockerイメージ	コンテナレジストリ(DockerHub)	コンテナランタイム(containerd)
オーケストレータ	マニフェスト(YAML)	-	設定データストア(etcd)	Pod、Deploymentなど

例えば、Kustomizeを使うとテスト・本番などの環境別のマニフェストの差分管理が容易になります。また、Telepresenceを使うとリモートのKubernetesクラスタを使ってアプリケーションのデバッグができます。ローカルにKubernetesクラスタを構築しなくても良くなるのです。

Skaffoldを使うと、フェーズ横断で管理することができます。アプリケーションの業務プログラムの変更を検知してイメージをビルドし、コンテナレジストリに登録できます。さらには、Kubernetes（Pod）の更新まで行ってくれます。

上記はあくまで開発ツールの一例ですが、ご自身の開発スタイルに合わせて、どのフェーズやレイヤを対象としたツールを活用するかをご検討いただくと良いでしょう。

Dev[Sec]Ops：セキュリティリスクに応じて求められる機能

DevOpsからDevSecOpsと呼ばれるようになり、開発の中でセキュリティの重要性が高く認識されるようになってきました。

IPAの「アプリケーションコンテナセキュリティガイド」によると、「コンテナ技術のコアコンポーネントの主なリスク」として以下が挙げられています。これらを全て目検や手作業で実施するのは非常に困難です。近年、こうしたセキュリティリスクへ対応する機能を持ったセキュリティツールが出てきました。

例えば、代表的なものとしては、Trivyが挙げられます。Trivyを用いると「イメージの脆弱性」や「埋め込まれた平文の秘密情報」の検知などが可能です。ツールを用いることで自動検出が可能なセキュリティリスクは、DevSecOpsのプロセスに組み込んでセキュリティを高めると良いでしょう。

リスク分類	内容
イメージのリスク	・イメージの脆弱性・イメージ設定の不備・埋め込まれたマルウェア・埋め込まれた平文の秘密情報・信頼できないイメージの使用
レジストリのリスク	・レジストリへのセキュアでない接続・レジストリ内の古いイメージ・認証/認可の不十分な制限
コンテナのリスク	・ランタイムソフトウエア内の脆弱性・コンテナからの無制限のネットワークアクセス・セキュアでないコンテナランタイムの設定・アプリの脆弱性・未承認コンテナ
オーケストレータのリスク	・制限のない管理者アクセス・不正アクセス・コンテナ間ネットワークトラフィックの不十分な分離・ワークロードの機微性レベルの混合・オーケストレータノードの信頼
ホストOSのリスク	・大きなアタックサーフェス・共有カーネル・ホストOSコンポーネントの脆弱性・不適切なユーザーアクセス権・ホストOSファイルシステムの改ざん

*　*　*

今回はクラウドネイティブな開発ツールに求められる機能をフェーズやレイヤ、DevOpsやDevSecOpsの観点から紹介しました。これらの開発ツールはあくまで補助的な位置付けであり、全てを自動化することを目的とする必要はありません。今回ご紹介した内容を基に、ご自身の開発スタイルに適したツールの組み合わせを、検討してみてはいかがでしょうか。