Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. IBM Cloud Pak for Multicloud Managementシリーズ(第2弾)"MCM CORE"

IBM Cloud Pak for Multicloud Managementシリーズ(第2弾)"MCM CORE"

投稿者:クラウド・テクニカルセールスエンジニア

IBM Cloud Pak for Multicloud Managementシリーズ(第2弾)"MCM CORE"

IBM Cloud Pak for Multicloud Managementシリーズ(第2弾)”MCM CORE”

第2回:MCM COREについて

こんにちは。NI+C小野です。

本ブログでは私が今年度より担当しているIBM Cloud Paksやコンテナ技術について、そこで得た知識や学びを紹介していきます。

第2回では、第1回にて取り扱ったIBM Cloud Pak for Multicloud Management(以下MCM)に内包されている、ソフトウェアの一つ”MCM CORE”について取りまとめていきます。

MCM説明画像.png

MCM COREの土台となる、IBM Cloud Paksや他の内包ソフトであるMonitoringについては第1回にて説明をしていますので、是非ご覧ください。
(https://www.niandc.co.jp/sol/tech/date20201009_1892.php)

目次

・MCM COREとは?

   -製品説明

   -3つの機能

・MCM COREの検証

   -検証概要

   -検証準備

   ー実際の検証内容

・まとめ

・MCM COREとは?

製品説明

MCM COREの主な機能としてはマルチクラウド環境にあるKubernetesクラスタの管理であり、多くの環境を統合的に管理することができます。

現在のコンテナ環境事情は、コンテナ環境の増加により管理が煩雑になりつつあります。
理由としては以下のような要因が考えられます。

<要因>
・部署、プロジェクトごとに別々な環境を利用
・管理者が把握しきれていない状況でデプロイした野良コンテナの乱立
・ガバナンス管理が困難
これらによりコンテナ管理者は、全環境にある一つ一つのコンテナや、脆弱性やポリシーのセキュリティ管理が困難になっています。
MCM COREは上記の課題を解決するためにご利用いただけます。

-3つの機能

MCM COREには3つの機能があり、これらを組み合わせることでクラスタ管理を容易にします。

>マルチクラスタの運用機能

マルチクラウド環境に対してKubernetesクラスタの払い出しや、既存クラスタの登録を実施する機能です。

2020年12月現在のサポート対象は、AWSのEKS、GCPのGKE、AzureのAKS、IBMのIKS、Red Hat OpenShiftが対応しております。

MCM COREからクラスタの払い出しや、クラスタの登録を行うことで、GUI上から各クラスタ状況を一目で確認でき、クラスタ管理を一つのプラットフォームにまとめることができます。

5.png

また、各環境をまたがって、クラスタの検索が可能です。

クラスタのリソース状況を検索でき、膨大な量のクラスタから簡単に目的のクラスタを探し出せます。

15.png

これらの機能により、クラスタの運用や管理を行います。

>アプリケーション管理機能

複数クラスタへのアプリケーション配布や、クラスタ間のアプリケーション移動を実施する機能です。

MCM COREから複数の環境にまたがるクラスタに対し、まとめてアプリケーションの配布や移動ができます。

3.png

また、アプリケーションのリソース情報を統合的に表示し、管理することも可能です。

アプリケーションごとのCPUやメモリの利用率をグラフ等で確認できます。

4.png

これらの機能により、アプリケーションの管理を行います。

>ガバナンス&リスク管理機能

企業ポリシーに対応するガバナンスやリスク管理機能の実装、コンテナ環境の脆弱性を検知する機能です。

MCM COREからポリシーに準拠しないクラスターを確認したり、脆弱性やコンテナの変更を検知できます。

↓ポリシーに準拠しないクラスターの確認画面
5.png

↓変更されたコンテナのリスト

6.png

また、脆弱性等を検知するポリシーもリストから選択が可能で、選択していくだけでポリシーを設定できます。

7.png

↑ポリシー選択画面

これらの機能によりガバナンスやリスクの管理を行います。

MCM COREではこれら3つの機能を活用することにより、複数クラスタの統合管理を実現します。

今回は、これらの中から、いくつかの機能に絞って検証を行いましたので、その際のまとめを記載します。

・MCM COREの検証

-検証概要

今回、実際に検証を行った環境は、以下のような環境となっております。

ほぼ、第1回の時に利用した環境と同じ環境を利用しました。

違いとしては、IBM Cloud Pak for Multicloud Managementの上にMonitoringではなくMCM COREが存在すること、

また、OpenShiftの上に検証で利用する管理対象コンテナが存在することです。検証環境図.png
〈MCM CORE導入環境構成〉

・MCMCORE

・IBM Cloud Pak for Multicloud Management

・OpenShift

・VMware vSphere

・ベアメタルサーバ(IBM Cloud)

〈管理対象 環境構成〉

・管理対象コンテナ

・OpenShift

・VMware vSphere

・ベアメタルサーバ(IBM Cloud)

上記環境にて行った検証は下記3つです。

検証一覧

1.クラスタ登録

2.脆弱性検知

3.コンテナ変更検知


検証内容としては、以下の通りです。

1.クラスタ登録

MCM COREにてクラスタを管理するため、MCM COREに管理対象となるクラスタを登録しました。

この検証にてMCM COREにクラスタを登録し、MCM COREを利用できるように検証しました。

第1検証.png

2.脆弱性検知

MCM COREよりコンテナに対して、脆弱性の検知を行いました。

今回は、ポリシーの設定方法や、実際にポリシー違反をした場合、どのように表示されるのか確認しました。

3.コンテナ変更検知

コンテナに変更が行われた場合、MCM COREにて検知されるのか検証を行いました。

今回は実際にコンテナ内のファイルを変更し、検知される内容を確認しました。

第3検証v1.png

-検証準備

今回は検証を行うための準備として、OpenShiftとMCM、MCM COREの導入を行いました。

ここでは各種導入について簡単に説明していきます。

今回の検証環境は、先ほど検証環境説明でも行ったように第1回とほぼ同じ構成で構築を行っています。

OpenShiftやMCMの導入は第1回と同じ作業なため、第1回の記事をご覧ください。

(https://www.niandc.co.jp/sol/tech/date20201009_1892.php)

また、MCM COREはMonitoringと違って、MCMを導入した時点で利用することが可能です。(Yaml変更作業無しで利用可能)

そのため、今回はMCMを導入した時点でMCM COREの導入も完了となります。

-検証前提条件

今回の検証における前提条件は下記の通りです。

・作業用PCが準備済みであること

・環境に接続可能なインターネット環境が設定済みであること

・管理対象となるクラスタやコンテナが設定済みであること

-実際の検証内容

ここからは実際の検証内容と検証手順について記載します。

1.クラスタ登録

MCM COREに管理対象となるクラスタを登録する機能を検証しました。

検証方法は、MCM COREにて管理対象クラスタの登録設定を行い、管理対象クラスタではエージェントを導入するため、MCM COREから生成されるコマンドを実行します。

その後、MCM COREにて、登録した管理対象クラスタが確認できるか、どのように表示されるのか検証しました。

検証の手順

<手順>

①MCM COREよりクラスタの追加を設定

②手順①で生成されたコマンドを管理対象クラスタで実行

③追加したクラスタをMCM CORE画面にて確認

次に各手順の詳細について記載します。

①MCM COREよりクラスタの追加を設定

MCM COREに管理対象のクラスタを追加するため、まずMCM CORE側でクラスタ追加の設定を行います。

画面右上にある[クラスタの追加]をクリックします。1.png

次の画面で下記POPが出てきますので、[インポートコマンド実行による、既存のクラスタ]をクリックします。

1.png

管理対象のクラスタ名を入力する画面になるので、クラスタ名を入力し、[コマンドの生成]をクリックします。

クラスタ名は任意のものでも問題ないですが、管理性を考え管理対象のクラスタ名と同様の名前にすることを推奨します。

また、名前空間に名前を入力することにより、入力した名前でクラスタをまとめることが可能です。

2.png

コマンドが生成され、画面に映し出されるので、コマンドをコピーします。

生成されたコマンドはこちらです。

curl -k -H “Authorization: Bearer <認証トークン>”

https://icp-console.apps.<MCMクラスタ名>:443/rcm/v1/clusters/aws-openshift/aws-openshift/import.yaml | kubectl apply -f –

このコマンドは管理するクラスタにて実行するので、忘れずにコピーしてください。
これでMCM CORE側の設定は終わりです。

3.png

②手順①で生成されたコマンドを管理対象クラスタで実行

管理対象クラスタの設定を行っていきます。

手順①で生成されたコマンドを管理対象クラスタで実行し、エージェントを導入します。

今回は上記に記載されているコマンドを、そのままCLIにて実行しました。

-コマンド例-

[root@hostname ~]# curl -k -H “Authorization: Bearer <認証トークン>” https://cp-console.apps.<MCMクラスタ名>:443/rcm/v1/clusters/nic-cluster/nic-cluster/import.yaml | kubectl apply -f –
customresourcedefinition.apiextensions.k8s.io/endpoints.multicloud.ibm.com created
namespace/multicluster-endpoint created
secret/klusterlet-bootstrap created
serviceaccount/ibm-multicluster-endpoint-operator created
clusterrolebinding.rbac.authorization.k8s.io/ibm-multicluster-endpoint-operator created
deployment.apps/ibm-multicluster-endpoint-operator created
endpoint.multicloud.ibm.com/endpoint created

これで、管理対象クラスタにエージェントが導入されます。

管理対象クラスタでの作業は終了です。

次は、MCM COREにてクラスタが追加されているか確認します。

③追加したクラスタをMCM CORE画面にて確認

手順②でコマンドを実行後、MCM COREでクラスタが追加されているか確認しました。

クラスタリストの画面を確認すると今回追加されたクラスタが表示されておりました。

4.png

-結果-

クラスタの追加は手順でもご覧頂いたように、3ステップほどで完了しました。

作業自体もクラスタ名を入力して、コマンドをコピーし、管理対象で実行するだけだったので、容易にクラスタ登録が可能なことをご理解頂けたかと思います。

つまり、複数のクラスタ環境があった場合でも、全てのクラスタ環境をMCM COREに登録するのは容易であり、統合管理を手軽に始めることができます。

2.脆弱性検知

MCM COREの脆弱性検知機能であるVulnerability Advisorを活用して、脆弱性の検知を行いました。

検証方法は、MCM COREが検知するように脆弱性のポリシー設定を行います。

そして、90日間パスワードを変更していないコンテナに対して、検知を行い、どのような表示がされるのか検証しました。

検証の手順

<手順>

①Vulnerability Advisorより設定されているポリシーの確認

②ポリシーを設定後、コンテナ一覧より各コンテナを確認

③コンテナを一つ選択、詳細を確認

次に各手順の詳細について記載します。

①Vulnerability Advisorより設定されているポリシーの確認

Vulnerability Advisorの画面へ移動し、右上の[ManagePolicies]を選択し、設定されているポリシーを確認します。
(Vulnerability AdvisoはMCMのホーム画面から選択できます。)

10.png


[ManagePolicies]を選択後、下記画面が表示されます。

こちらの画面では、ポリシーを設定できます。

今回は、デフォルト設定のまま、検証を行いました。

ポリシーを設定後、画面下にある[Submit Policy]をクリックします。

これで、ポリシーの設定は完了です。

11.png

②ポリシーを設定後、コンテナ一覧より各コンテナを確認

ポリシーの設定は完了したので、実際に検知されているのか確認します。

検知はVulnerability Advisorが、1日1回自動で行ってくれるので、ユーザが実行する必要はありません。

また、ユーザによって、検知の間隔を変更することができます。

上記タブから[List Containers]を選択し、コンテナ一覧を表示します。

12.png


[List Containers]タブを選択すると下記コンテナ一覧が表示されます。

listkonntena.png

③コンテナを一つ選択、詳細を確認

コンテナ一覧からコンテナを選択すると、コンテナ単位でポリシーのチェックができます。

脆弱性検知結果.png


今回の検証では、コンテナのパスワードが90日以上変更されていない場合、検知される設定なので、下記画像のように赤く表示されています。

90日パスワード.png

[Risk Analysis]タブを選択すると、リスク分析を確認することができ、設定したポリシーに対して、コンテナがどれくらいリスクがあるのかグラフにて表示されます。

リスク分析では、CVSSに準拠したリスク分析が行われるため、信頼性の高いスコアを確認できます。
※CVSSとは、脆弱性の汎用的な評価方法であり、ベンダーに依存しない共有の評価方法で脆弱性を評価できます。
※CVSSに該当するリスクを含むコンテナが存在しないため、リスクが0件という結果です。

脆弱性リスクグラフ.png

-結果-

ポリシーを設定し、違反していた場合、正常に検知されました。

ポリシーの設定については、リストから選択していくだけのため、簡単にポリシーを設定できます。

マルチクラウド環境に対して、統合的に脆弱性を検知したり、統一されたポリシーで脆弱性を検知する機能はOpenShiftやKubernetesには実装されていない『MCM CORE特有の機能』です。

これによりマルチクラウド環境であっても安全に、安心してコンテナを利用していくことができます。

3.コンテナ変更検知

コンテナに変更が行われた際、その変更を検知する機能について検証を行いました。

検証の方法は管理対象であるコンテナに変更を加え、MCM COREが変更を加えたコンテナを確認し、コンテナの変更が検知するか確認しました。

実際にコンテナを変更する方法として、コンテナ内にファイルを作成しました。
この変更を検知されるか、どのように表示されるのか検証しました。

検証の手順

<手順>

①検知対象であるコンテナにログインし、ファイルを作成

②MCM COREのMutation Advisorを選択し、検知画面へ移動

③変更したコンテナをリストから選択、詳細の確認

次に各手順の詳細について記載します。

①検知対象であるコンテナにログインし、ファイルを作成

コンテナの変更を検知しているか確認するため、検知対象であるコンテナにファイルを生成します。

実際にコンテナにログインし、コマンドによって .date.outというファイルを作成しました。

今回は名前空間・ns-1のコンテナを変更しております。

-コマンド例-

[root@hostname ~]# oc project ns-1
Using project “ns-1” on server “https://api.<クラスタ名>:6443″.
[root@hostname ~]# oc get pod java2-1-q7tfx
NAME READY STATUS RESTARTS AGE
java2-1-q7tfx 1/1 Running 0 3d18h
[root@hostname ~]# oc rsh java2-1-q7tfx
sh-4.2$ echo `date` > .date.out
sh-4.2$ cat .date.out
Tue Jul 14 06:30:26 UTC 2020
sh-4.2$ ls -la
-rw-rw-rw-. 1 jboss root 29 Jul 14 06:30 .date.out
sh-4.2$ exit
[root@hostname ~]#
コンテナの変更はこれで完了です。
次は実際に変更が検知されているか、MCM COREにて確認します。

②MCM COREのMutation Advisorを選択し、検知画面へ移動

実際に検知されているか確認するため、MCM COREのコンテナ変更検知機能であるMutation Advisorに移動し、画面にて検知結果を確認します。

Mutation Advisorは、コンテナ変更の検知を随時行っているので、ユーザが検知の実行をする必要はありません。

実際に画面に移動すると、検知対象であるコンテナがリストで表示され、先ほど変更を加えた名前空間・ns-1の横に1/24というエラー通知が表示されています。

(24個のコンテナ中、1つのコンテナに問題があるという表示です。)

変更検知.png

③変更したコンテナをリストから選択、詳細の確認

更を加えた名前空間・ns-1をリストから選択し詳細を確認します。

選択すると詳細画面が表示され、手順①にて追加した.date.outファイルが表示されました。

ファイル名や変更された時間が記載されています。

変更検知.png

また、[Process Mutation]をクリックすると、実行されたコマンドも確認することができます。

コマンドに関しても、実行された時間や結果が表示されます。

変更コマンド.png

-結果-

実際に変更したコンテナが検知され、MCM COREの画面より確認できました。

表示された内容は、変更した内容だけに留まらず、実行されたコマンドが全て検知されていました。

コンテナ管理者はコンテナに変更が加えられた際にその変更を検知・確認することができます。
他者による悪意ある変更なども検知できるため、安全にコンテナを運用・管理することができます。

このマルチクラウド環境のコンテナ変更検知機能はOpenShiftやKubernetesにはない、『MCM CORE特有の機能』です。

・まとめ
本記事でMCM COREについて少しでも理解を深めるための一助となっていれば幸いです。
本記事でご紹介した機能は一部となっております。
今回検証したMCM COREの機能は3つですが、その他にも以下の機能があります。
・複数クラスタへのアプリケーション配布
・クラスタ間のアプリケーション移動
今後も定期的に情報を発信していきたいと思いますのでお楽しみにしていただければ幸いです。
12月はIBM Cloud Pak for Multicloud Managementの最後の1製品である「Infrastructure Management」をテーマに取り上げる予定です。
この記事に関するご質問等があれば「こちら」からお問い合わせください。
担当者からご連絡させていただきます。

ページのトップへ