「DX時代の Self-Managed Kubernetes 構築・運用・セキュリティのポイント」セミナーイベントレポート

コンテナ時代の到来と Kubernetes の将来

株式会社野村総合研究所
マルチクラウドインテグレーション事業本部 ビジネスIT基盤推進部
上級テクニカルエンジニア 平田 正 氏

　現在IT業界ではコンテナ、マイクロサービス、DevOpsが三つ巴で互いに影響を及ぼしながら高速に発展しています。アプリケーション開発の中心にあるのはDevOpsとマイクロサービスで、これらはデプロイ間隔の短縮や管理範囲の縮小を実現します。これにコンテナが加わることで開発環境と本番環境の差異を吸収し、素早い構築と運用の負荷を下げることができるようにもなります。

　ある程度の規模がある開発プロジェクトでは、開発と環境構築は担当チームが分かれ、開発者が新たなアプリケーション環境を必要とするとき、社内ネットワーク管理者に環境構築を依頼する必要があります。場合によっては1週間ほどの待ち時間が生じることもあります。しかしコンテナの宣言的な言語YAMLを使うことで、開発者は環境構築の主導権を得られるようになりました。もちろん、ネットワーク管理者は日常的なオペレーションを予めポリシーで定めておくことができます。

　代表的なコンテナにKubernetesがありますが、Kubernetesにはまだ「難しい」というイメージが強くあります。その理由は、（コンテナランタイムという）新しいレイヤが追加されたことで、運用や監視のベストプラクティスをどう適応させるかが不明確となり、結果「難しい」というイメージにつながっているのではと推測しています。また、コンテナを導入するなら、本質的にはDevOps文化への移行も成し遂げなくてはなりません。組織文化の変革も必要になります。

　Kubernetesは敷居いと感じられるかもしれませんが、将来のインフラでコンテナ技術は避けられず、来たるコンテナ時代に向けて備えておくべきです。

Self-Managed Kubernetes の構築と運用のポイント

株式会社野村総合研究所
マルチクラウドインテグレーション事業本部 ビジネスIT基盤推進部
主任テクニカルエンジニア 澤頭 毅 氏

　Kubernetesサービスといえば、Google Cloud PlatformならGKE（Google Kubernetes Engine）、AWSならEKS（Amazon Elastic Kubernetes Service）、Microsoft AzureならAKS（Azure Kubernetes Service）などがあります。これらはクラウドプロバイダーが管理しているため「プロバイダーマネージド型」と呼ぶことができます。

　一方、自分たちで管理するのは「セルフマネージド型」となります。このセルフマネージド型を選択する理由には、自社で保有しているコンピュートリソースを有効活用したい、オンプレミス環境から外に出したくない顧客情報などを扱うためなどがあります。なかにはプロバイダーマネージド型では提供されない最新機能を利用したい場合も想定されます。

　そのセルフマネージド型のKubernetes環境を設計する時のポイントはクラスタのバックアップとリストア、それから証明書です。

　まずはバックアップとリストアです。Kubernetesのオブジェクトはetcdに格納されるため、etcdのスナップショットを定期的に取得しておく必要があります。また、バックアップ先にはetcdとは物理的に異なるサーバーを使い、障害時にはスナップショットをリストアし、再起動するようにしましょう。

　なおバックアップしたい対象がPersistentVolume（PV）を利用していた場合には、バックアップとリストアを実施するのは管理を担当するチームになります。VeleroやKasten K10などのツールを活用することも有効です。

　実際に障害が起こると、現場は判断に迷うことが多くあります。なぜならネットワークの瞬断などで一時的にノードがメンバーから外れて、再接続することが繰り返されることもあるからです。そのため、予め判断基準を作っておいたほうがいいでしょう。

　続いて証明書です。Kubernetesのクラスタでは多種多様な証明書が用いられます。kubeletがAPI Serverの認証をするためのクライアント証明書や、API Serverのエンドポイント用のサーバー証明書等々です。OpenSSLやCFSSLを用いて手動で証明書を作成するほか、kubeadmを用いるのも有効です。ツールごとに仕様が異なるので、証明書の有効期限切れには注意してください。

　セルフマネージドのKubernetesは運用負荷が高くなるため、要件と照らし合わせて得られる効果を見極めるようにしてください。

何を気を付けるべき？ Kubernetes 活用における課題と Sysdig による解決策

SCSK株式会社
プラットフォームソリューション事業部門 ITエンジニアリング事業本部ミドルウェア第二部第一課
関谷 祥子

コンテナやKubernetes運用では、アーキテクチャが複雑でブラックボックス化する傾向があります。大規模で分散したコンテナやサービスになると、複雑かつ短命です。こうした特性がトラブルシューティングに支障を与えることもあります。例えば「CrashLoopBackOff」。何らかのエラーにより、Podが停止と起動を繰り返す現象です。コンテナの実体となるPodが停止により消えるため、原因調査が難しくなります。

　また、コンテナ運用では、セキュリティ対策もまだ模索している段階と言えます。コンテナで運用するアプリケーションのセキュリティについて、アメリカ国立標準技術研究所（NIST）が発行した「アプリケーションコンテナセキュリティガイド」（SP800-190）に詳しい説明があります。これによると、イメージ、レジストリ、オーケストレータ、コンテナ、ホストOSにおけるリスクが挙げられています。

こうした背景から、コンテナ運用では可視化や障害検知をいかに実現するかが重要となります。本日ご紹介するのは、コンテナ環境の統合モニタリングとセキュリティプラットフォームを実現する「Sysdig Secure DevOps Platform」(以降「Sysdig」)です。コンテナ内部や通信状況のモニタリング、コマンド実行履歴の記録、コンテナに潜む脆弱性の発見などができるので、Sysdigは不正アクセスやサイバー攻撃の検知に非常に有効です。

　Sysdigはネットワークプロトコルアナライザ「Wireshark」の共同創作者となるロリス・ディオニアニ氏が開発しました。SysdigモニターとSysdigセキュアの2つからなりたちます。今ではゴールドマンサックス、メルカリ、NTTデータなど、世界で400社以上が活用しています。OSSをベースに開発されていることが特徴で、SysdigモニターはPrometheusとSysdig Inspect、SysdigセキュアはFALCOやAnchoreがベースにあります。

　なお、Kubernetesの認定試験となるCKS（Certified Kubernetes Security Specialist）では、参考ドキュメントとしてSysdigとFALCOが挙げられています。ここからSysdigはKubernetesでは標準的な技術として認められていると考えられます。

　Sysdigではコンテナ環境に特化したアプローチである「コンテナ・ビジョン」と呼ばれる仕組みを提供しています。ノードに対してコンテナ形式でデプロイされたSysdigエージェントが、ホストのカーネルにアクセスし、Linuxのシステムコールを採取し可視化します。

監視や可視化だけではなく、トラブルシューティングやフォレンジックまで一気通貫で提供できるソリューションであるのがSysdigの大きな特徴です。

　セミナーでは、Sysdig Secure DevOps Platform製品のデモとして、Sysdigモニター機能を用いてブラックボックスなコンテナやコンテナ間の通信状況を可視化し、アプリケーション・コンテナの可用性を確保する仕組みをご紹介しました。さらに、アプリケーション開発のライフサイクル（Build、Ship、Run）にあわせて、考慮すべきセキュリティ観点とSysdigセキュア機能の活用シーンもご紹介しました。

　最後にSCSK株式会社プラットフォームソリューション事業部門 ITエンジニアリング事業本部ミドルウェア第二部第一課 石川愛彦は、「Sysdig は、①可視化、②障害検知　③解析　④セキュリティ対応を行うことができ、モニタリングとセキュリティの機能を提供している唯一の製品です」と締めくくりました。