Cloud Nativeなマインドを身につけKubernetes等のバージョンアップに備える

はじめに

この記事は『NTTテクノクロス Advent Calendar 2019』の21日目の記事です。

本日はOpenStackやCloud Foundry等のIaaSやPaaSをメインとしたチームに所属しており
普段はCloud Foundryやコンテナ関連のOSS製品を扱う業務や定額制チケットサービスが担当業務であるNTTテクノクロスの森川が担当します。

昨年のNTTテクノクロス Advent Calendar 2018では、『コンテナ標準化時代における次世代Buildpack『Cloud Native Buildpack』について』という記事を執筆し、コンテナの要素技術の標準化の注目技術について紹介しました。

今回の記事を書くにあたり、昨年の内容と関連のある内容を執筆しようと考えネタ探しをしていたところ、直前に『配達人の主人公』が未開拓の行路の先にある目的に荷物を届けるため、事前に地形を確認しながら様々な装備を準備し、道を開拓していくゲームをプレイしました。

目的地に向かうためにしっかりとした準備を行う姿がCloud Nativeに向かう為のステップを紹介するCloud Native Trail Mapに通じると思い、今回はコンテナ化の次の取り組みについて書くことにしました。

Cloud Native Trail Map

Cloud Native Trail Mapとは、Cloud Native Computing Foundation(CNCF)が掲げる
Cloud Nativeに向かう為の指針であり、以下の順番で向かう事をおススメしています。

1. CONTAINERIZATION
2. CI/CD
3. ORCHESTRATION &APPLICATION DEFINITION
4. OBSERVABILITY & ANALYSIS
5. SERVICE PROXY, DISCOVERY, & MESH
6. NETWORKING & POLICY
7. DISTRIBUTED DATABASE & STORAGE
8. STREAMING & MESSAGING

重要な部分は、『CONTAINERIZATION』でDockerなどを使ってコンテナ化に取り組んだ次のステップは、Kubernetes等が含まれる『Orchestration & Application Definition』ではないという点です。

『Cloud Native』に抱く人々の理想と現実

「そろそろコンテナに関して取り組みたいので調査しなくては」と様々なカンファレンスや勉強会・文献等をチェックされている方であれば、『Cloud Native』というキーワードをよく見かけると思いますが、Cloud Nativeが実践できていると、様々な要素のコード化が進み自動化が図られていきます。

例えばアプリケーションの機能追加があった場合、以下のようなステップが存在します。

• 機能追加によるコードの改修とリリースまでのステップ(例)
  1. コードの変更
  2. コンテナイメージのビルド
  3. ビルドしたイメージを元にアプリの単体テスト
  4. テスト環境へデプロイ & テスト
  5. 本番環境へデプロイ

理想としては1~5のステップを自動化し、1日に数回～数百回といったリリースを実践できている状態ですが、現実的には数か月に1回の機能追加の度に、手動で検証環境にデプロイ+人手によってテスト項目を消化し、リリースを行うというケースも多いと思います。

そういった場合、リリースするのは数か月に1回なのでCI/CDは導入しないと判断（やった方が良いのはわかっているが優先度を下げる）というケースが多いのではないでしょうか？

Cloud Nativeを実現するためのプロダクトの多くで、古いバージョンを使い続けて問題が起きた際に既知のissueのやり取りの内容だけで解決できなかった場合、コミュニティにissueを上げても「まずは最新版へ！」というやり取りを経験上よく見かけます。

コンテナの実行イメージとして標準化されている範囲の動作はある程度保証されたとしても、それらを取り巻く周辺ツールや、アプリケーションが利用するライブラリ等、多くの組み合わせが複雑に関係し、実際にその組み合わせの検証せずに動作を保証するのは、非常に困難と言えます。

「アプリの実装は変えてないから多分問題ないはず！」の罠

「開発者はアプリ開発に専念出来る」というのがメリットのCloud Foundryに数年に渡って関わってきた私の経験からも 「アプリの実装は変えてないから多分問題ないはず！」とアプリ改修以外の要因でビルド・テスト・デプロイ等を実施すると面白いくらいにどこかしらの場所で失敗するのを見てきました。

失敗する要素の例としては以下のようなものが挙げられます。

• ビルド資材の取得元URLの変更や一時的なサーバダウン

• manifestで利用できるオプションの変更等

Positive Motivation vs Negative Motivaion

機能追加等を契機としたアップデートをPositive Motivationによるアップデートとした場合、
アプリを動かしサービスを提供し続ける中で、避けて通れないものとして、Negative Motivationによるアップデートの脆弱性対策があります。

脆弱性対策を起因とした場合において重要な点は

• 脆弱性の対策は発生タイミングがコントロールできない
• 放置した場合、社会に大きな影響を及ぼす可能性がある

という点で内容に応じて速やかな判断や対応が求められます。

コンテナセキュリティスキャン

コンテナのビルドについては昨年紹介したCloud Native Buildpack等を活用する事で効率的なビルドが行えるようになりますが、作った後のイメージに既知の脆弱性を持ったライブラリが無いかを検証する方法として、『コンテナのセキュリティスキャン』が注目されています。

手法としてのトレンド

ThoughtWorks社が年に2回テクノロジーのトレンドを紹介しているTechnology Radarでは『HOLD』→『ASSESS』→『TRIAL』→『ADOPT』という評価で様々な種類の開発手法・ツール・プラットフォームやプログラミング言語等を紹介しています。

Technology Radarの2019年11月版の「Techniques」カテゴリでは、コンテナのセキュリティスキャン手法『Container security scanning』は以下のような評価の推移となり、今年の11月に『ADOPT』になりました。

• Container security scanningの評価推移

• 2016/11	2017/03	2019/04	2019/11
  ASSESS	ASSESS	TRIAL	ADOPT

• (参考）Dockerの場合の評価推移

  2014/01	2014/07	2015/01	2016/04	2016/11
  ASSESS	TRIAL	TRIAL	ADOPT	ADOPT

ツールとしてのトレンド

同じくTechnology Radarの2019年11月版の「Tools」カテゴリでは、1バイナリで導入しやすい脆弱性スキャンツールの『Trivy』が紹介されています。
今回が初めての掲載ですが、評価としては『TRIAL』に位置付けられており、
元々は個人の方が趣味で作ったプロダクトからセキュリティ企業に買収という部分からも注目のプロダクトであるといえます。

(参考URL）https://opensource.tokyo/n/nc96669b27365

• Trivyの評価推移

  2019/11
  TRIAL

Trivyの動作イメージ

• alpineの最新版(2019/12頃時点)

  軽量なコンテナイメージであるalpineを例にスキャンをしてみますと、最新版では1件も検出されません。

  ubuntu@docker01:~$ trivy alpine:3.10.3
  2019-12-10T08:56:46.893Z        INFO    Detecting Alpine vulnerabilities...
  
  alpine:3.10.3 (alpine 3.10.3)
  =============================
  Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
  

• alpineの最新版より古いバージョン

  1つ前のバージョンを指定してみると3件検出されました。
  検出＝必ずアップデートが必要という訳ではありませんが、自動的に検出する事で次のアクションが行いやすくなりますので、積極的にCI/CDに加えたい要素だと思います。

  ubuntu@docker01:~$ trivy alpine:3.10.2
  2019-12-10T08:57:21.214Z        INFO    Detecting Alpine vulnerabilities...
  
  alpine:3.10.2 (alpine 3.10.2)
  =============================
  Total: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 2, HIGH: 0, CRITICAL: 0)
  
  +---------+------------------+----------+-------------------+---------------+--------------------------------+
  | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
  +---------+------------------+----------+-------------------+---------------+--------------------------------+
  | openssl | CVE-2019-1549    | MEDIUM   | 1.1.1c-r0         | 1.1.1d-r0     | openssl: information           |
  |         |                  |          |                   |               | disclosure in fork()           |
  +         +------------------+          +                   +               +--------------------------------+
  |         | CVE-2019-1563    |          |                   |               | openssl: information           |
  |         |                  |          |                   |               | disclosure in PKCS7_dataDecode |
  |         |                  |          |                   |               | and CMS_decrypt_set1_pkey      |
  +         +------------------+----------+                   +               +--------------------------------+
  |         | CVE-2019-1547    | LOW      |                   |               | openssl: side-channel weak     |
  |         |                  |          |                   |               | encryption vulnerability       |
  +---------+------------------+----------+-------------------+---------------+--------------------------------+
  
  

おわりに

現在Kubernetesが活用できている人々は、これまでにも「IaaSの備えるAPIを使ってVMを作成し自動的にテストしてリリースまでしよう」というような『Puppet』, 『Chef』, 『Ansible』等の様々なツールを試行錯誤しながら自動化に取り組み、更なる効率化を求めた形として取り組んでおり、Cloud Nativeを実践するにはこれまでの自動化の営み同様、日々試行錯誤が求めらているという現実があります。

そのためコンテナ化から始めてみたという方は、次のステップとして、是非コンテナイメージのビルド自動化や今回紹介したコンテナのセキュリティスキャンを用いたサイクルを通して
コンテナの扱い方に慣れたのちに、Cloud Native Trail Mapの次のステップである『Orchestration & Appliation Definition』へ歩んで頂きたいと思うともに、そういった取り組みをする方の支えとしての活動を今後とも取り組んでいきたいと思います。

明日はNTTテクノクロス Advent Calendar 2019の22日目としてboono さんのKubernetesの運用に関する記事です。

引き続き、お楽しみください。