More than 5 years have passed since last update.

Rancherのセキュリティについて整理 ~公式ブログ記事より~

Posted at 2019-05-02

1. はじめに

Docker、Kubernetesが注目を集め、これらツールの本番導入が進む中で、コンテナ利用時のセキュリティに対する関心は高まっています。RancherはKubernetesのマルチクラスター環境を管理するツールであり、コンテナ周りのツールの中でも注目を集めるものの一つです。そんなRancherはセキュリティに対してどんな機能を提供しているのか気になっていたところ、Rancherの公式ブログから一本の記事が公開されました。今回はこちらを翻訳しつつ、それ以前に必要となるであろうコンテナ利用時のセキュリティについても簡単に整理することで、理解を深めて見たいと思います。

2. コンテナを利用する際のセキュリティ

コンテナのセキュリティを考える上で、まずはじめに押さえるべき情報の一つとして、2017年にNISTの公開したNIST SP 800-190が挙げられます。こちらではコンテナを利用する際にリスクとなりうるポイントと、それに対する一般的な対応策を紹介しています。

2-1. コンテナを利用する際に生じるリスクの種類

そもそもコンテナを利用する際に生じるリスクには、大きく2つの種類があります。

コンテナやコンテナイメージが内包するリスク：アプリケーションの持つ脆弱性などが該当します。こちらは別のNIST SPで紹介されている、data-centric system thread modelingを用いて評価しています。

※data-centric system thread modeling：システム内部にある特定の型のデータに対する防御に焦点を当てる手法。例えば「ラップトップ内にある顧客情報」というデータに対するセキュリティを、攻撃サイド（脆弱性、攻撃因子など）と防御サイド（リスク、セキュリティコントロールなど）から評価する。

コンテナの誤った利用：ユーザの誤操作やセキュリティ的に脆弱な設定が該当します。システム管理者の誤った設定や命令により、他のコンテナやホストOSなどが攻撃を受ける可能性が生じます。

2-2. コンテナを利用する際のセキュリティ上のポイント

コンテナを利用する際のセキュリティ上のポイントは5つあります。それぞれの問題点の項目を以下に記載します。

イメージリスク
- コンテナイメージの持つ脆弱性
- コンテナイメージの設定の不備
- マルウェアの埋め込み
- 平文パスワードの埋め込み
- 信頼できないイメージ（公式イメージでないものなど）の利用
レジストリリスク：
- レジストリへの安全でない接続
- 古いコンテナイメージの残存
- レジストリへのアクセス時の不十分な認証・認可
オーケストレータリスク：
- 管理者権限の不適切な割り当て
- 認証のないアクセス
- コンテナ間ネットワークトラフィックの不十分な隔離
- workloadの重要度による隔離がされていない
- ノードの信頼性
コンテナリスク：
- ランタイムソフトウェアの持つ脆弱性
- コンテナとコンテナ・ホストOS間の通信が制限されていない
- コンテナの設定の不備
- アプリケーションの脆弱性
- 計画外・許可されていないコンテナの存在
ホストOSリスク：
- 攻撃される範囲が大きい
- カーネルの共有
- ホストOSコンポーネントの脆弱性
- ユーザごとのアクセス権が適切でない
- ホストOSファイルシステムの無断での変更

2-3. オーケストレータリスクについて

上記5項目の中で、Kubernetes及びRancherと密接に関係するものは「オーケストレータリスク」です。オーケストレータリスクの問題点について、もう少し詳しく見てみます。

問題点：

管理者権限の不適切な割り当て：
- オーケストレーションツールは、それに関係する人は全員が管理者権限を持つべきとされています。しかし実際は、一つのオーケストレーションツールで複数の異なるアプリケーションを動作させ、複数のチームによって管理される場合もあります。悪意のあるユーザ、あるいは注意散漫なユーザによって、目的とは別のコンテナを操作する可能性が生じます。
認証の無いアクセス：
- オーケストレーションツールはそれ自身の認証ディレクトリサービスをもち、それはすでに組織で利用しているディレクトリとは別のものです。これはアカウントの管理が煩雑になり、十分管理できなくなることにつながります。またオーケストレーションツールの持つアカウントが孤立することにもつながります。このようなアカウントはしばしば強い権限を持ち、これらの「妥協」はシステム全体の妥協につながります。
- コンテナはオーケストレーションの管理するストレージを利用することが多く、それらはホスト特有のものではありません。コンテナはクラスター内のノードのいずれかで動くため、すべてのノードでデータが利用できる必要があります。また多くの組織では暗号化が必要なデータを管理しています。
コンテナ間ネットワークトラフィックの不十分な隔離：
- ノード間の通信は仮想オーバーレイネットワークを介して行われます。このネットワークはオーケストレーションツールで管理され、既存のネットワークセキュリティや管理ツールには（通信が暗号化されている、などにより）不明瞭なものとなります。これは運用やセキュリティでのメリットをもたらす一方で、セキュリティ上の見えないシナリオが存在することになります。
- また、より重要な問題として、同じ仮想ネットワークを共有する別のアプリケーションからのトラフィックが発生する可能性があります。異なる重要度のアプリケーションが同じ仮想ネットワークを共有する場合、ネットワークを介した攻撃リスクにされされることになります。
workloadの重要度による隔離がされていない：
- オーケストレーションツールでは、workloadのスケールと数量を管理することに焦点が当てられます。これはつまり、デフォルトでは異なる重要度レベルのworkloadを同じホストに配置されうることを意味します。例えば重要な財務データを扱うホスト上でグローバルにアクセスされるWebサーバが稼働する可能性があるということです。Webサーバに重大な脆弱性があれば、金銭的なデータが危険にさらされることになります。
ノードの信頼性：
- オーケストレーションツールはもっとも基盤のノードであるため、オーケストレーションの設定に誤りや弱い部分があればシステム全体をリスクにさらすことになります。あり得るケースとしては以下のようなものがあります： ①認証されていないホストがクラスターに参加しコンテナを動かす、 ②認証に使われるキーペアがすべてのノードで共有される、 ③オーケストレータ、管理者、ホストなどの間での通信が暗号化・認証されていない。

3. Kubernetesのセキュリティ

コンテナオーケストレーションツールには様々なものがありますが、現状ではKubernetesがデファクトスタンダードとなっています。Kubernetesは柔軟な設定が可能であり、セキュリティに関する設定も多く含まれます。
CNCF(Cloud Native Computing Foundation)は、Kubernetesを利用する際のセキュリティに関する記事を公開しています。この記事はすでに別記事にて和訳・解説されていますので、ここには概要のみを記載します。

元記事リンク：https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/
解説記事リンク：https://qiita.com/mamomamo/items/1651b8f9e44938c0de15

※（補足）私も稚拙ながら先日和訳いたしました。

3-1. Kubernetesのセキュリティにおける9つのベストプラクティス（概要）

最新バージョンにアップデートする：
- Kubernetesは３ヶ月ごとに新しいバージョンをリリースし、その度にセキュリティのアップデートがされています。そのため最新バージョンを利用することでセキュリティも担保されます。
RBACを利用する：
- RBACを使うことでユーザごとの役割とアクセスできるリソースをコントロールできます。
Namespaceを利用してセキュリティの境界を設定する：
- Namespaceを使うと論理的な名前空間の隔離が行えます。
重要なworkloadを隔離する：
- 重要なworkloadを別のクラスターなどに配置することで、別のコンテナとのランタイムなどを共有することによる攻撃リスクを軽減できます。

※（補足）こちらを実装するにはtaint/torelationを活用する方法があります。

Cloud Metadataへのアクセスをセキュアにする：
- GKEで利用できるmetadata concealmentを使うことで、クラウドサービスで利用できる重要なメタデータ（kubeletのadmin credentialなど）へのアクセスをセキュアにします。
クラスターのNetwork Policyを設定する：
- Network Policyを使うことで、コンテナアプリケーションのネットワークアクセスを制御できます。
クラスター全体に対してPod Security Policyを適用する：
- Pod Security Policyを利用すると、workloadが動作するための条件をあらかじめ設定できます。
ノードのセキュリティを厳重にする：
- ホストの設定の確認、ポートの制限、管理者権限での操作の制限などの設定によって、ノードセキュリティを向上できます。
監査ログを有効にする：
- 有効にすることで、特にAPIの呼び出しについて監視することができます。

この記事で紹介する範囲は、前段での「オーケストレータリスク」で取り上げた項目の大部分をカバーしているため、Kubernetesのセキュリティに関してある程度包括的な範囲での対策を紹介していると言えそうです。

※（補足）もちろんここに書かれた対策をすればKubernetesのセキュリティが完璧というわけではありません。さらなる情報については、以下のリンク先を参考にしてみてください。
https://kubernetes-security.info/

4. Rancherでのセキュリティ対策について

ここまでの記事の内容を踏まえて、ではRancherのセキュリティ対策はどのようにすれば良いのか？ということを、Rancherの公式ブログが公開した記事で紹介しています。
以下に簡単な和訳を載せていますが、この記事は前段のKubernetesのセキュリティベストプラクティスに呼応する形で書かれています。そのため、Kubernetesでの機能と対応して、Rancherではどのように対策をしているかがわかりやすいと感じました。

元記事リンク：https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/

4-1. Kubernetesにおける「よりセキュアな」セキュリティのベストプラクティス（和訳・要約）

はじめに

先日「Kubernetesのセキュリティに関する9つのベストプラクティス」なる記事が公開されました。この記事で紹介されている推奨項目は（セキュリティを考える際の出発地点として）良いですが、この記事はGKEにかなり依存しています。Googleを利用している方はGKEを利用することが良い解決策となりますが、AWS、Azure、DigitalOcean、あるいは自分たちのインフラを持つ人々にとっては助けとならないこともあります。

そんな人々にとって、Rancherは強力な解決策です。

Rancher Labsはセキュリティについて真剣に捉えています。創設者の一人であるDarren Shepherdは、2018年12月にCVE-2018-1002105として発表されたバグを発見しました。

※（補足）上記CVEはKubernetesで初めて報告された大規模なセキュリティ脆弱性になります。

この記事では、先日のCNCFの公開した推奨項目に対して、Rancher及びrkeがどのようにポイントを満たすかを紹介します。

RBACを利用する

rkeではデフォルトでrbacが有効化されています。もしあなたがrkeやKubernetesだけを使ってるなら、クラスターをセキュアにするため、アカウント、ロール、bindingを設計する責任があります。
Rancherを使ってる場合は、セキュアなクラスターをインストールするだけでなく、それらクラスターとの通信をRancher Serverを通じて仲介します。RancherはAD(Active Directory)やLDAPなどバックエンドの認証プロバイダを取り込んでいます。これらを利用することで、既存の統合認証を、それがどの環境で動いているかにかかわらず、Kubernetesクラスターに拡張することができます。

※（補足）RancherではGUI上で「Global」→「Security」→「Role」→「Grant resources」と操作することで制御画面に遷移することができます。

RancherはGlobal/Cluster/Projectレベルでroleを有効にするため、あらゆるスケールでのロール定義を可能にします。

※（補足）公式ページはこちら
https://rancher.com/docs/rancher/v2.x/en/admin-settings/rbac/

このような「デフォルトでのRBAC」と「認証・認可の操作」を組み合わせることで、セキュアなクラスターを実現することができます。

Namespaceを利用してセキュリティの境界を設定する

Kubernetesでは「default」というNamespaceを特別な用途で使っているため、defaultを使うことは推奨しません。その代わりにアプリケーションごとにNamespaceを作成し、それらをロジカルグループとして定義することを推奨します。
RancherではProjectという抽象レイヤーを定義しています。あるひとつのProjectはNamespaceの集合体で、それらNamespaceにはロールがマッピングされています。あるProjectへのアクセス権を持つユーザは、それ以外の権限のないProjectは閲覧することができません（たとえ権限のあるProjectと関連するworkloadだとしても）。これにより、効率的に単一のクラスターでマルチテナンシーを実現することができます。

Projectを使う事で、ひとつのクラスター内で複数のNamespaceへのアクセス権を与えることが簡単になります。これにより、コンフィグの重複を最小限にしたり、ヒューマンエラーを減少させることができます。

重要なworkloadを隔離する

「もしworkloadが攻撃されたらどうなるか？」というのを考えるのは良いことです。攻撃の影響範囲を小さくするために行動を起こすことは、攻撃による影響をゼロにすることにはつながりませんが、（対策を打つために）時間を稼ぐことには貢献するかもしれません。
Kubernetesはtaintとtolerationを設定することができ、それによってPodをどのノードやホストにデプロイするかをコントロールすることができます。
RancherでもKubernetes labelを利用してworkloadのスケジューリングをコントロールすることができます。taintやtolerationに加えて、podに対して「must/should/can」レベルでラベル付けすることができます。また静的な環境であれば、特定のノードを指定してスケジューリングすることもできます。

※（補足）RancherでのNode scheduling機能は、workloadをデプロイする際に設定することができます。workloadごとに特定のノードでのみ動かすか、条件を満たすノードを自動でピックするか選択できます。
https://rancher.com/blog/2018/2018-08-29-scheduling-options-in-2-dot-0/

※（補足）「must/should/can」レベルとは、GUI画面上の「Require ALL of:/Require Any of:/Prefer Any of」にそれぞれ対応した言い回しと思われます。

Cloud Metadataへのアクセスをセキュアにする

この指摘は重要なメタデータが「盗まれたり誤利用されることがあり得る」ことを示していますが、それが「いつ、どうやって」リークするか、という情報がありません。元記事ではKubeCon NAでのshopifyの講演を引用しています。この講演では、GKEの機能であるmetadata concealmentについて紹介していますが、むしろ最初にcredentialがリークしたサービスがGoogle Cloud metadata APIであったことをここに記すべきです。
（現在まで）同様の脆弱性が報告されたクラウドプロバイダは他に存在しません。
もしrkeをベアメタルやクラウドインスタンス上で使う場合は、metadata APIからcredentialデータがリークできない状態にする必要があります。
もしGKEを利用する場合は、metadata concealmentを有効化することを推奨します。
クラウドプロバイダーは、APIを通じてアクセスできるメタデータ上に、credentialデータを配置するべきでないでしょう。それが利便性のためであったとしても、不必要なリスクです。

クラスターのNetwork Policyを設定する

rkeクラスターではデフォルトでcanalを使用します。CanalとCalicoはどちらもNetworkPolicyをサポートしています。またCanalを利用する場合、RancherのデプロイしたクラスターではProjectNetworkPolicyをサポートします。ProjectNetworkPolicyを有効化することで、workloadは同じProject内の別のworkloadと通信することができます。またSystem Project（ingress controllerのようなクラスターワイドなcomponentを含む）は全てのProjectと通信できます。
初期バージョンのRancherではProjectNetworkPolicyがデフォルトで動作していましたが、これが混乱をもたらすこともありました。現在はデフォルトではオフになっていますが、簡単に有効化することができます。

※（補足）KubernetesではNetwork Policyを利用してPod間の通信を制御することができます。
https://kubernetes.io/docs/concepts/services-networking/network-policies/

※（補足）記事中ではProjectNetworkPolicyと紹介されていますが、正しくはProject Network Isolationです。Project間でのPodの通信を許可するか否かを選択できます。

クラスター全体に対してPod Security Policyを適用する

Pod Security Policy(PSP)は、クラスターで動かすために必要な要素を定義します。Rancher/rkeでクラスターを作成する場合、PSPをデフォルトで有効化するかどうか選択することができます。

PSPのrestricted / unrestrictedは、rkeとRancherでは同じものであり、インストール時に有効化するものは同一のものです。Rancherでは無制限でPSPを作成することができます（globalレベル）。管理者はPSPを定義し、Rancherで管理するクラスターに適用します。これは、RBACの設定に関するものと同様、セキュリティの設定を１箇所にとどめ、ポリシーの設定をシンプルに保ちます。

※（補足）RancherのGUI画面からは「Global」→「Security」→「Pod Security Policy」の順に操作することでPSPを作成・編集することができます。また「各クラスター」→「Edit」→「Additional Cluster Options」から有効化することができます。

（セキュリティの設定を）簡単にできれば、より多くの人がそうするでしょう。

ノードのセキュリティを厳重にする

これはKubernetesに限ったことではなく、一般的なポリシーです。あなたが制御しないトラフィックに関するもの（Kubernetes内部で利用するアプリケーションを動作させるユーザトラフィックなど）は何であれ、攻撃対象範囲が小さい状態で稼働するべきです。不要なサービスは無効化・アンインストールしましょう。sshでのrootアクセスを制限し、sudo時にはパスワードを要求するようにしましょう。これらはベーシックなセキュリティ対策の一例です。
Rancherはホストに対して、Dockerをサポートすること以上のことは何も要求しません。rkeはsshだけ要求し、それはKubernetesがサポートする最新版のDockerをインストールするでしょう。
さらに攻撃範囲を小さくしたい場合は、RancherOSの利用を検討しましょう。RancherOSは全てのプロセスがDockerコンテナとして作動する軽量Linux OSです。System Dockerでは最小限のプロセスしか稼働せず、また実際のworkloadでは単一のDockerインスタンスしか動作しません。これはつまりデフォルトでセキュアということを意味します。

※（補足）RancherOSは、CoreOSなどと同様コンテナを稼働させることに特化したOSであり、必要最小限の機能しか有していません。
https://rancher.com/docs/os/v1.x/en/

監査ログを有効にする

Rancher Serverはrke cluster上で動作しているため、Kubernetesのaudit loggingを有効化するのに加えて、Rancher server自身の（API callsに対して）audit loggingを有効化することも重要です。これによって、全クラスターでのユーザの実行内容（何が起こったか、誰がいつ、どのクラスターで実行したか）がわかるようになります。
またこれらのログを別のサーバに送り出すことも重要です。RancherはSplunkやElasticsearchなど様々なsyslogエンドポイントに接続することが可能であり、またそこからダッシュボードの作成やアラートの生成もできます。

※ （補足）Rancherのaudit loggingについては公式ページで方法を紹介しています。
https://rancher.com/docs/rancher/v2.x/en/installation/options/api-audit-log/
例えば以下のように環境変数を見ると、audit logの設定が確認できます。

[root@Rancher ~]# docker exec -it a348cc5167aa env

~ 中略 ~

AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log
AUDIT_LOG_MAXAGE=10
AUDIT_LOG_MAXBACKUP=10
AUDIT_LOG_MAXSIZE=100
AUDIT_LEVEL=0

~ 中略 ~

[root@Rancher ~]#

Ongoing Security

真にセキュアなKubernetesクラスターを実現するには、9つ以上の変更が必要になります。RancherではCIS Benchmarkを満たすためにhardening guideやself assessment guideなどを公開しています。
あなたがセキュリティについて真剣であれば、Rancher、rke、そしてRancherOSはあなたをサポートするでしょう。

5. おわりに

RancherはKubernetesの持つセキュリティ機能の改良・強化をすることで、セキュリティ機能を提供します。Rancherはコンテナオーケストレーションツールのため、それ以外の分野についてはセキュリティに関する機能は提供していないようです。
特にKubernetes単体では設定が煩雑である部分を簡便にすることで、セキュリティの設定をしやすくしているのが特徴的であると感じます。記事中ではPod Security Policyなどが該当する箇所です。
Rancherを利用するケースとしては、社内ネットワークのような「閉じた」ネットワークからアクセスし、コンテナ化したアプリケーションをKubernetesクラスター上で稼働させる、というのが多いのではと勝手に予想しており、セキュリティの機能は現状でも十分と考えられるかもしれません。
一方で「Rancherはセキュリティについて真剣に考えている」というブログ中の言葉通り、Rancher v2.3ではセキュリティを強化すると記載しています。具体的にはセキュリティスキャンやプライベートレジストリ・イメージスキャン機能を追加するとのことで、今からリリースが楽しみです（セキュリティ以外にもWindows GAサポート、ノードのセルフヒーリング機能など、要注目の内容）。また公式ページでレジストリに依存すると記載していたイメージスキャンについては、Clairと統合することで機能を備えるようです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up