SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
目次
はじめに
今回の投稿ではNIST SP800-190でのリスク対策について、RKSではどのような設定がなされているか、またRKSでNIST SP800-190のリスク対策を設定する場合の対案をご紹介させていただきます。
本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。
RKSを知る！ 概要＆連載リンク集
NIST SP800-190とは
NIST SP800-190はシステムおよびセキュリティ管理者やアプリ開発者など向けに、仮想化技術の一つである「コンテナ」に関するセキュリティ上のリスクと対策についてまとめ、要件を提示しています。コンテナの技術および環境を導入する際のセキュリティ確保に向けた指針となります。
https://www.ipa.go.jp/files/000085279.pdf
今回はコンテナアプリケーションのリスクの中からオーケストレータのリスクと対策に絞りご紹介させていただきます。
NIST SP800-190が提示するオーケストレータへのリスク
NIST SP800-190で提示されるオーケストレータのリスクについて下記でご紹介させていただきます。
また、下記に記載するリスクの内容については「NIST SP800-190 アプリケーションコンテナセキュリティガイド」を参考とし、要約したものとなります。
◆制限のない管理者アクセス
悪意のあるユーザがオーケストレータに影響を及ぼさないようにアクセス権の設定を徹底する。
◆不正アクセス
オーケストレータが独自の認証ディレクトリサービスと連携している場合、認証サービスがオーケストレータでの認証権限も高い権限を保持している場合は、不正アクセスの対象となる可能性が高いため、認証ディレクトリサービスの権限も合わせて実施する必要がある。
◆コンテナ間ネットワークトラフィックの不十分な分離
ノード間のトラフィックは仮想オーバーレイネットワークを介してルーティングされるが、既存のネットワークセキュリティおよび管理ツールからは確認することができない。
そのため、別途コンテナネットワークをモニタリングできる環境が必要となる。 また、機微性の高いアプリケーションと仮想ネットワークを共有している場合、重要度の高いアプリケーションがリスクにさらせてることになる。
◆ワークロードの機微性レベルの混合
ワークロードは最も利用可能なリソースを保持しているノードに配置されるため、重要度がことなるコンテナが混在してしまう。そのため、コンテナのリスクに合わせて配置するコンテナを調整する。
◆オーケストレータノードの信頼
環境内のノードには以下のようなリスクが含まれるため、ノード自体のセキュリティを徹底する。
– 不正なホストがクラスタに参加し、コンテナを実行すること
– 一つのクラスタのホストの侵害が、クラスタ全体に侵害をもたらす。例えば、同じ認証用の鍵ペアが、すべてのノードで共有されている場合があること
– オーケストレータと DevOps 担当者、管理者、およびホスト間の通信が暗号化されず、認証もされないこと
NIST SP800-190のリスク対策に伴うRKSとしての設定状況、および回避策
上記で提示したNIST SP800-190のオーケストレータのリスクに対して、RKSの設定状況と、リスク回避策についてご紹介させていただきます。
◆制限のない管理者アクセス
・設定状況
RKSはデフォルトでRBACの設定がなされていない。
初期状態のKuberntesと変わらない状態でデプロイされているため、クラスタにアクセスできればオーケストレータに影響を与える操作が可能となってしまう。
・回避策
Nodeや特定のリソース群に対してRBACでの認証、認可の設定を実施する。デフォルトではコアコンポーネントリソースを管理しているNamespace[kube-system]は特定のユーザを除いて、閲覧のみの権限にするなど厳重に設定をする。
※参考https://knowledge.sakura.ad.jp/21129/
◆不正アクセス
・設定状況
RKSでは認証ディレクトリサービス(SSO含む)は展開していないため、連携サービスによる不正アクセスを考慮する必要はない。 しかしながら、Access Tokenを用いたクラスターへのアクセスを採用しているため、管理者アクセスと合わせてトークン情報の管理が必要となる。
・回避策
ディレクトリサービスと連携し、多要素認証を適用できる場合は、シングルサインオンなどを適用する。
RKSでは多要素認証を採用していないため、アクセス管理はRKS上でのAccess Tokenを管理する方法となる。
◆コンテナ間ネットワークトラフィックの不十分な分離
・設定状況
RKSはWeaveNetを採用しているため、WeaveNetのモニタリング方針を確認する必要がある。 RKS自体はネットワークモニタリングサービスを展開していないため、独自でネットワークモニタリングを設計、構築する必要がある。 仮想ネットワークの分離については、RKSないしマネージドサービスの特性上、ネットワークの分離をクラスター内で行うことは出来ないため、別途対案が必要となる。
・回避策
WeaveNetではPrometheusと連携することでWeaveNetを監視することができる。Prometheusの構築やWeaveNetとの連携設定が必要となるが、NISTが提示しているリスクをクリアすることができる。
RKSの特性上、単一のノードでネットワークの分離はできないため、セキュリティレベルごとにクラスターを作成することで、仮想ネットワークの分離が可能となる。
◆ワークロードの機微性レベルの混合
・設定状況
基本的に特定のリソースをノードに配置する場合はkuberntesの基本機能であるTaint / Tolerationを使用して管理する必要がある。
RKSではデフォルトでTaint / Tolerationの設定はないため、リソースの重要性に合わせて設定する必要がある。
・回避策
リソースの重要性に合わせてTaint / Tolerationを設定する。 また、NISTのリスク対策として、コンテナ自体をセグメント化(処理に合わせてコンテナごとに分散させる)することが最良としているが、オーケストレーションの管理項目ではないので割愛とする。
◆オーケストレータノードの信頼
・設定状況
RKSないしマネージドオーケストレーションではWorkerNodeの管理は基本的にベンダ側の管理となるため、詳細なセキュリティ情報の確認はできない。
RKSではWebUI上でWorkerノードのスケールアウトが可能である。WorkerNodeが削除された場合、稼働しているリソースはスケールアウト後に新規のWorkerNodeに移行されるため、リスクは少ないがスケールアップ実施の権限などを適切に設定する必要がある。
・回避策
RKSのWorkerNodeのセキュリティを侵害しないために、信頼できるアプリケーション以外をデプロイしないよう徹底する必要がある。 また、WorkerNodeの利用者側で操作できる権限を適切にIAMで管理することが必要となる。
さいごに
今回はNIST SP800-190とRKSのセキュリティ状況を比較した記事となりました。
NISTに関わらず、CIS Kubernetes Benchmarkなど標準セキュリティツールなどでコンテナ環境をよりセキュアに運用していくことがより重要視されているため、過去の記事と合わせてお読みいただくことで、RKSに関わらずコンテナ環境のセキュリティについて深い理解が得られると考えております。
ここまでお読みいただきありがとうございました！
Be the first to comment