Running Helm in production: Security best practices

稼働中にHelmを走らせる：セキュリティーのベストプラクティス

10 min readOct 21, 2019

Helm は今では Kubernetesのための一番ポピュラーなパッケージマネージャーになっています。Helmの役割はChartsを使ってKubernetesアプリケーション管理をサポートすることです。Helm chartはKubernetesクラスターに直接インストールできるただの「パッケージ」です。Helm chartはとても役に立つ優れたツールです。というのも、これはConfigMaps, Deployments, Volumes周りの全ての複雑なことをアブストラクト化してくれるからです。これがなければ、Kubernetesのアプリケーションをデプロイする時に一つ一つ扱う必要があります。

稼働中にHelmを使う場合、（例えばセキュリティーポリシーを伴ったKubernetesの中のような場合）、セキュリティー関連の不具合を避けるためにこのツールを正しくセットアップする方法を理解していなけばいけません。この記事では、そういったセキュリティー上の問題を回避するためのベストプラクティスを説明しながらHelmにおけるセキュリティー上の課題について、また Kubeappsを使ってそういった問題を克服するためにBitnamiをどのように生かすかをご紹介したいと思います。Kubeappsはオープンソースで、ウェブベースのUIです。Kubernetesのアプリケーションをデプロイしたりマネージメントしたりすることができます。

Installing Helm

Helmをインストールするのは簡単です：一度 helm CLIを手に入れ、シングルコマンドを実行するだけでOKです。

$ helm init$HELM_HOME has been configured at /home/andres/.helm.Tiller (the Helm server-side component) has been installed in your Kubernetes cluster.Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.To prevent this, run `helm init` with the --tiller-tls-verify flag.For more information on securing your installation, see: https://docs.helm.sh/using_helm/#securing-your-helm-installationHappy Helming!

それでは、Kubernetesの中に自分の大好きなアプリケーションをインストールする準備が整いました！でも、ちょっと待ってくださいね。他にもちょっと注意を向けないといけないところがあります。

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.

確かにこれは邪魔です。もう少し深く掘り下げてみましょう。

Helm security challenges

Bitnami Kubernetesの開発者であるAngus Lees氏はある記事でHelmのセキュリティー上の課題についての詳細について書いています。その主な問題点は、HelmがTillerという名前のサーバーサイドを必要とすることです。このコンポーネントは、ユーザーに代わってHelm chartに特定の何かをインストールする目的でKubernetes APIに接続する役割を担っています。

Tillerは常に管理者特権が必要になる：もしユーザーがClusterRoleやCustomResourceDefinition (CRD)のようなクラスター全体のエレメント（要素）を含むチャートをインストールしようと思った場合、Tillerはそれらのソースを生成するか削除するために十分な権限を保持している必要があります。
Tillerは認証されたユーザーにはアクセス可能である必要がある。つまり、クラスターの有効なユーザーはチャートをインストールするためにアクセスする必要があるのです。

そうすると、明らかなセキュリティー上の問題が出てきました。つまり、権限の昇格です。突然、最低限の権限を持っているユーザーはまるで、自分がアドミニストレーターになったようにクラスターに関わることができるようになります。もしKubernetesポッドが、危険に晒されるような状況になると問題はさらに大きくなります。つまり、危険にさらされたポッドもまたアドミニストレーターと同じようにクラスターにアクセス可能になるからです。これは本当に問題です。

Mitigating the issues

Helm の公式文書には、それらの問題を最小化できるヒントが書かれています。ただ、残念ながらまさにこの問題に直結した解決策は載っていません。

Tiller permissions（パーミッション：許諾権）を狭めることは、確かな選択肢になるでしょう。ただ、これは私たちのニーズに合うということはありません。おそらく、あなたはクラスターのアドミニストレーターがクラスター全体のコンポーネントを伴ったチャートをインストールできるようになればいいと思っているはずです。
TLS証明書を伴ったTillerエンドポイントを確保すること。この証明書を使ってユーザーじゃ有効なユーザーを確保するだけではなく、それに接続できるTillerの証明書へアクセスする必要もあります。危険にさらされたポッドはTillerにアクセスすることができません。というのも、デフォルトで証明書へのアクセスを制限する必要があるからです。問題は、その証明書へのマネージングアクセスを維持することが難しいということです。今クラスターのアドミニストレーターは全ての新規ユーザーを拒否するか受諾するかのルールを適用する必要があります。
Tillerのインスタンスをネームスペースごとに実行する。こうすることで、他の特権はそのままにしつつ、的確なインスタンスへのTillerの許諾権を狭めることができます。もう一度言いますが、この解決策の欠点は、維持することの難しさなのです。現在もリソースを無駄にしながら、デプロイメントが重複している状況にあります。

Tillerless and Helm v3

Helmメンテナー（維持する者）はHelmのサーバー側が原因の脆弱性を認識しています。そのため、次のメジャーバージョンでは、Tillerを入れないでしょう。もし、この新しいバージョンで何が起きているか知りたいのであれば、こちらで技術案を見てみてください。残念ながら、公式リリースの日程はまだ不明ですが、当面、現在のバージョン２を使用していく必要があるようです。

Tillerless Helmというもの関して説明しておきたいと思います。これは、Kubernetesクラスターの中というよりはむしろ自分のローカルホストでTillerを走らせるということです。Tillerは実行するユーザーの認証情報を使用して一時的に実行されるため、特権を昇格させることはできません。

ただ、このアプローチにもまた弱点があります。今はまだクラスターにインストールするチャートについての情報を保存する必要がありますね。それは、この作戦でアプローチしようと考えている人はみな、使用を許可されたネームスペースをコンフィギュアする必要があります。そして、チャートをデプロイするためにいくつかのコマンド（異なるターミナルで）を実行しなければいけません。これを行ってくれるプラグインがありますが、どの場合においても、これはデフォルトのエクスペリエンスからは転換します。

Using Kubeapps and Tiller-Proxy

Kubeapps とTiller-Proxyの使用についてです。Kubeapps はウェブベースのUIで、Kubernetesクラスターの中江アプリケーションをマネージメントします。言い換えれば、これがあれば、ウェブインターフェイスを使って helm CLIなしにHelm chartをインストールしたり、検索したりできるようになります。

Kubernetes Role-Based Access Control (RBAC：役割ベースのアクセス制御機能)はKubeappsを支持しています。これは、サインインするためにKubernetes APIトークンが必要だということを意味します。Kubernetes APIトークンは簡単に手に入ります。こちらのスタートガイドを見て頂くとやり方が書いてあります。一旦、ユーザーがログインすると、特定のKubernetesユーザーと認証され、権限を昇格することができなくなります。これを実現するために、Tillerを対象とするアクションを検証する認証プロキシを開発しました。この単純化された図で、その方法を説明しています。

ユーザーはチャートのインストールをリクエストする（例えば：bitnami/wordpress)
チャートをインストールする前にKubeappsはTillerでマニフェストを解決する。このマニフェストはチャートのために必要なリソースを全て持っています。
それぞれのリソースのために、Kubeappsは認証されたユーザーが既定のネームスペースにそれを生成できる許可を持っているかどうかをチェックします。そのために、Kubeappsは認証されたAPIを使用します。ユーザーが要求されたアクションを実行する権限を持っているかどうかとは異なります。（例えばネームスペース“デフォルト”の中にデプロイメントを生成するなど）
リクエストが有効な場合のみKubeappsはチャートをインストールする。

このようなセットアップで、Kubernetesクラスターのための単一のTillerを使ってセキュリティー面の不安を伴うことなく、Helm chartをインストールすることができます。

HelmのセットアップやKubeappsセキュリティーに興味を持たれた方はこちらのstep-by-step ガイドをご参照ください。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。