コンテナセキュリティの利点と課題
Container Journalの記事で、コンテナセキュリティの利点と課題が3つずつ紹介されています。それぞれについて私の見解を述べたいと思います。
課題
Containers are complex.
アプリケーションエンジニアにとってインフラレイヤは基本的にブラックボックスであり、今までの経験を活かしてセキュリティを考慮した設計をする必要があります。コンテナという馴染みのないレイヤが増えたことにより、必要以上に複雑に感じてしまっていると私は思っています。 VMと同様に、コンテナ導入が一般的になれば、複雑さもある程度解消されていくのではないかと思っています。
Lack of isolation.
本質的にコンテナとVMではisolationのレベルが異なります。時折「コンテナはVMよりもセキュアじゃないから使えない」という指摘をしてくる方もいますが、コンテナとVMは全く別物ですので、要件を踏まえた上で、コンテナを使うかどうか議論すべきでしょう。
Ecosystem complexity.
今でこそ、オーケストレーターはKubernetesがデファクトとなっていますが、以前はオーケストレーターでさえ、Swarmkit, Kubernetes, Cattleなどさまざまなものが乱立していました。今後もしばらくはこの状態が続くのではないかと私は思います。 目利きに自身がない場合は、垂直統合されたソリューションを買ってくるのが、最も確実だと思います。
利点
Immutable infrastructure.
コンテナの利点の一つにアップデートのしやすさが挙げられます*1。必然的にセキュリティパッチも即座にあてることができます。レガシーなシステムだとセキュリティパッチをあてるのにも１ヶ月かかることがありますから。
Fast updates.
上とほぼ同じですが、コンテナ化するとはマイクロサービスアーキテクチャを選択することになりますので、小さいアプリケーションを独立して即座にアップデートすることが可能となります*2。
Open ecosystem.
コンテナ界隈には多種多様なOSSが存在しています。腕に自身のある会社であれば、これらを有効活用して、迅速に自分たちのサービスを開発することが可能となります。
コンテナは、今後一般的に使われる技術になるのは間違いないですし、これらの課題に対するベストプラクティスも徐々に確立されていくと、私は思っています。
コンテナ運用に関する7つのベストプラクティス
Google Cloud Blogに、Kubernetes上でコンテナを運用に関するベストプラクティスを紹介する記事がポストされました。運用を容易にするためにアプリケーションの設計をどうすべきかが、わかりやすく書いてある良い記事でしたので簡単に紹介します。英語が得意でない方も、短い記事ですのでぜひ元記事をご参照ください*1。
Google Kubernetes Engine上でコンテナを運用することを前提にしてある記述もありますが、Amazon EKSといった別サービスや、オンプレに自ら構築して運用する際にも参考になると思います。
1. Use the native logging mechanisms of containers
コンテナ化されたアプリケーションのログの収集については見解が分かれるところであり、DockerやKubernetes導入時に悩むポイントの一つでもあります。この記事では、
Write your logs to stdout and stderr and they will be shipped, stored and indexed automatically for you.
アプリケーションログを標準出力に吐いて、Stackdriver Loggingなどの、Kubernetesに統合されたロギングメカニズムを利用することを推奨しています。
2. Ensure that your containers are stateless and immutable
コンテナ化することを前提にアプリケーションを設計する際に、statelessかつimmutableにすることを推奨しています。途中でアプリケーションコンテナが落ちて、別のノードで起動しても問題なく動くよう設計する必要があります。
初心者が陥りがちな問題の一つに、実際に動くノードを意識したコンテナのイメージを作ってしまい、結果的にノードごとに異なるイメージを用意することになることがあります。そういった問題を解くためには、SecretsやConfigMapなどを利用して設定情報の管理は外部に任せましょう。
3. Avoid privileged containers
コンテナに特権を与えない。コンテナ化することで限定的とはいえisorationされているのですから、それを自ら壊すような真似はやめましょう。
4. Avoid running as root
コンテナ内で実行するアプリケーションをrootとして実行することは避けましょう。アプリケーションが未知の脆弱性を突いてコンテナから抜け、ホストのrootとして実行される可能性があります。
5. Make your application easy to monitor
ロギングと同様にアプリケーション監視もシステム運用をする上で欠かせない要素の一つです。Kubernetesクラスタの監視でよく利用されるものの一つにPrometheusがあります。アプリケーションを独自ロジックで監視するためには、Prometheusにmetricsを渡すためのエンドポイントが必要になるので、予め監視も意識した設計をしましょう。
6. Expose the health of your application
Kubernetesには、アプリケーションが正常に動作しているか確認するために、Liveness and Readiness probesという方法があります。
これらを利用するためには、監視同様エンドポイントが必要になります。
7. Carefully choose the image version
コンテナイメージのタグは慎重に選択しましょう。もしlatestを選択してしまうと、pullするたびに異なるイメージを利用するという問題にあたる可能性があります。
*1:本ブログでは、元記事の翻訳ではなく、筆者独自の見解が追加されているため、鵜呑みにせず原文にあたることをおすすめします。
Kubebuilder: Kubernetes APIを開発するためのSDK
Kubernetesブログで、Kuberbuilderに関する記事がポストされました。
Kubebuilderは、KubernetesのCRD (Custom Resource Definition)を利用して、独自のKubernetes APIとカスタムコントローラを構築するためのSDK (Software Development Kit) です。 これを利用し独自APIとコントローラを開発することで、MySQLやSpark, CassandraといったアプリケーションをKubernetesのPodと同じように管理することができるようになります。つまり、アプリケーションをStatefulSetやSevice、ConfigMapのコレクションではなく、ファーストクラスのAPIで管理可能となります。
Kubebuilderを利用せずに独自コントローラを開発するには、
However, while it has been possible for trailblazers to build new Controllers on top of the raw API machinery, doing so has been a DIY “from scratch” experience, requiring developers to learn low level details about how Kubernetes libraries are implemented, handwrite boilerplate code, and warp their own solutions for integration testing, RBAC configuration, documentation, etc.
と記事に書かれているように、Kubernetesについて深い知識が必要でしたが、Kubebuilderを利用することで詳細が隠蔽されるため、比較的容易にコントローラを開発することができるようです。
Kuberbuilderの書籍もあるようなので、興味がある方は試してみたらいかがでしょうか。
PrometheusがKubernetesに続きCNCFのGraduatedプロジェクトになりました
モニタリングツールとして広く使われているPrometheusが、CNCFのGraduatedプロジェクトとなったことを発表しました。
Kubernetesに続く卒業となります。CNCFがホストするプロジェクトは多くあり、既に商用で利用されているOSSもありますが、現在のところGraduatedは、KubernetesとPrometheusの2つだけです。Graduation Stageに到達するためには、CNCFの定めた規準を満たす必要があり、両者の成熟度や安定度は高いといえるでしょう。 既にPrometheusを利用してる企業も多くあるかと思いますが、今後ますます案件が増えそうです。
記事では、incubatingからgraduatedとなるまでに、Prometheusコミュニティであったさまざまな出来事について述べています。
・We completely rewrote our storage back-end to support high churn in services
・We had a large push towards stability, especially with 2.3.2
・We started a documentation push with a special focus on making Prometheus adoption and joining the community easier
筆者も、Prometheus2.0でPrometheusのTSDBがスクラッチで書き換えられた話は、当時驚いた記憶があります。
OpenMetricsがCNCFのSandboxプロジェクトとなるなど、モニタリングの重要度は今後も高いと思いますので、Prometheusコミュニティが、Graduatedとなったことでどのようになっていくのか楽しみです。
Kubernetesのパッケージマネージャ: Helmを試してみよう
数ヶ月前にCNCFのIncubation-leveのプロジェクトとなったKubernetesのパッケージマネージャHelmに関する記事が、CNCFブログにポストされましたので、これを参考にしつつ試してみました。
Helmとは
HelmはKubernets上にアプリケーションコンテナをPodとしてデプロイすることを容易にすることを目的としています。KubernetesをLinuxなどのオペレーティングシステムと位置付けた時に、Helmはyumやaptといったパッケージ管理システムの役割を果たします。
KubernetesではPodをデプロイする際にManifestを定義しますが、HelmではChartsと呼ばれるアプリケーション定義を記述するそうです。物は試しということでHelmを利用してPodをデプロイしてみようと思います。
前提
Helmを試すには、自由に利用可能なKubernetesクラスタが必要です。minikubeを利用するのがもっとも簡単ですので、環境がない方はインストールしてみてください。 techlunch.hatenablog.com
インストール
インストールはとても簡単で以下のコマンドを実行するだけです。
$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash $ helm init
WordPressを動かしてみる
Chartsとして提供されてるアプリケーションを探すには次のコマンドを打ちます。
$ helm search NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.0 2.1.1 Scales worker nodes within agent pools ... stable/wordpress 2.1.8 4.9.8 Web publishing platform for building blogs and ...
今回は、WordPressをサンプルとしてインストールします。
$ helm repo update
これで完了です。WordPressとバックエンドのMariaDBの2つのPodが動作してることが確認できます。
$ kubectl get pods NAME READY STATUS RESTARTS AGE intended-aardwolf-mariadb-0 1/1 Running 0 1m intended-aardwolf-wordpress-646bd6955b-vj4px 1/1 Running 1 1m
HelmコマンドでもChartがインストールされていることを確認できます。
$ helm list NAME REVISION UPDATED STATUS CHART NAMESPACE intended-aardwolf 1 Sun Aug 12 15:08:58 2018 DEPLOYED wordpress-2.1.8 default
Kubernetesの導入の敷居の高さにはさまざまな理由があるのですが、一つはKubernetesマニフェストを書くことだと思っています。 Helmを利用することで、よく利用するアプリケーションが簡単にKubernetes上にデプロイできるようになるので、ますますKubernetesユーザは増えるかもしれません。
Helmについては、今後もしばらく動向をウォッチしていきたいと思います。
OpenMetricsがCNCFのSandboxプロジェクトになることが発表
OpenMetricsが、CNCFのSandboxプロジェクトになりました。CNCFによってホストされているプロジェクトは、数多くありますが、プロジェクトの成熟度でいうとSandboxは一番下に位置付けられています。「卒業」を示すGraduated projectは、現在のところKubernetesとPromehteus*1のみとなります。
VMwareが開発したHarborも最近Sandbox入りすることが発表されており、クラウドネイティブ界隈でのCNCFの存在感はますます大きくなってきていると言えるでしょう。
OpenMetricsは具体的にどのようなものなのか気になるところですが、記事には、
The open source initiative, focused on creating a neutral metrics exposition format, provides a sound data model for current and future needs of users, and embeds this into a standard that is an evolution of the widely-adopted Prometheus exposition format. While there are numerous monitoring solutions available today, many do not focus on metrics and are based on old technologies with proprietary, hard-to-implement and hierarchical data models.
という記述がありますので、OpenMetricsはソフトウェアというよりは、監視サーバに送るメトリクスの標準的なメッセージフォーマットやデータモデルを定義することを目的にしているように見えます。
コンテナの監視はPrometheusが使われることが多く、アプリケーション自身の監視もPrometheusでモニタリングできるように、独自Exporterを作成して監視していますが、事実上のデファクトであるPrometheusを参考にしつつ、その他の監視ツールも含めて、標準的な仕様を定義することを目的としているのかもしれません。
*1:Prometheusもここ数日の間にGraudatedになったばかりです。
CNCFブログにKubernetesのRBACに関する記事がポストされました。
少し前の話になりますが、CNCFブログにKubernetesのRBACに関する解説記事がPOSTされました。
記事によると、RBACはKubernetes1.6でベータ版となりましたが、当初は不満を抱えるユーザも少なくなく、StackOverflowやGithubでさまざまなissueがあげられていたそうです。なぜなら、ほとんどのドキュメントやサンプルがRBACを考慮したものではなかったからです。*1
ただ、RBACが重要であるということは、当然全員認識してしていたようです。全てのリソースを管理者権限で操作するなど、商用環境ではできないので。記事では以下のような機能が必要であると述べられています。
- さまざまなプロパティをもつ複数のユーザを用意し、適切に認証
- ユーザやユーザグループが実行できる操作の制御
- Pod内プロセスが実行できる操作の制御
- Namespaceの特定リソースのvisibilityの制御
英語が得意な方は、次のプレゼンも、是非ご参照ください。 youtu.be
また、KubernetesのRBACについて学ぶ前に、ロールベースアクセス制御(Role-based access control: RBAC)について勉強しておくと、より理解が進むと思います。RBACは一般的な技術ですので、日本語でもさまざまな解説記事がでていますが、概要を理解するには、Wikipediaの記事が良いでしょう。
商用環境でKubernetesを利用する場合は、RBACの利用は避けて通れませんので、商用導入を検討してる方は、是非勉強して見てください。また、RBACを使いこなすにはKubernetesで管理できるリソースやAPIについても勉強していく必要があります。APIドキュメントを参考に、さまざまなAPIを実際に打ち込んで学んでいくのが良いでしょう。
*1:現在は修正されているようです。
