VMware Cloud FoundationでのApache Log4j脆弱性の対応について
今回は、Apatch Log4jに深刻な脆弱性「CVE-2021-44228/CVE-2021-45046」が見つかった問題についてです。
Apache Log4jにはLookupと呼ばれる機能があり、ログとして記録された文字列から、一部の文字列を変数として置換します。その内、JNDI Lookup機能が悪用されると、遠隔の第三者が細工した文字列を送信し、Log4jがログとして記録することで、Log4jはLookupにより指定された通信先もしくは内部パスからjava classファイルを読み込み実行し、結果として任意のコードが実行される可能性があります。
VMwareの複数製品においても、その影響が公表されています。
対象のプロダクトや回避策等に関しては、以下VMSA-2021-0028から確認可能です。
今回、一部のVCF製品(Cloud Builder/SDDC Manager)の回避策が公開されてましたので
実施してみました。
Cloud Builder CVE-2021-44228のworkaround
本回避策は全てのVCF 3.xと4.xのCloud Builderに適応可能です。
Cloud BuilderにSSHで接続する
suコマンドでrootに昇格
admin@vcf-cb01 [ ~ ]$ su
imagingサービスの停止
root@vcf-cb01 [ /home/admin ]# systemctl stop imaging
imagingサービスが停止しているか確認
root@vcf-cb01 [ /home/admin ]# systemctl status imaging
以下のファイルを編集する前にバックアップを取得しておく
/opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh
root@vcf-cb01 [ /home/admin ]# cp /opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh /opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh.orig
/opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.shを編集する
root@vcf-cb01 [ /home/admin ]# vi /opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh
Before
nohup /etc/alternatives/jre/bin/java -jar -Dserver.port=$VIA_SERVICE_PORT -Dspring.config.additional-location=$VIA_EXTERNAL_PROPERTIES_PATH,$VIA_DB_PROPERTIES_FILE -Dserver.servlet.context-path=$VIA_CONTEXT_PATH $VIA_SERVICE_PATH < /dev/null >>$LOGFILE 2>&1 &
After
nohup /etc/alternatives/jre/bin/java -jar -Dserver.port=$VIA_SERVICE_PORT - Dlog4j2.formatMsgNoLookups=true -Dspring.config.additional-location=$VIA_EXTERNAL_PROPERTIES_PATH,$VIA_DB_PROPERTIES_FILE -Dserver.servlet.context-path=$VIA_CONTEXT_PATH $VIA_SERVICE_PATH < /dev/null >>$LOGFILE 2>&1 &
以下のファイルを編集する前にバックアップを取得しておく
/opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.sh
root@vcf-cb01 [ /home/admin ]# cp /opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.sh /opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.sh.orig
/opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.shを編集する
Before
nohup /etc/alternatives/jre/bin/java -jar -Dserver.port=$SECOND -Dspring.config.additional-location=$VIA_DB_PROPERTIES_FILE $name < /dev/null >>$LOGFILE 2>&1 &
After
nohup /etc/alternatives/jre/bin/java -jar -Dserver.port=$SECOND -Dlog4j2.formatMsgNoLookups=true -Dspring.config.additional-location=$VIA_DB_PROPERTIES_FILE $name < /dev/null >>$LOGFILE 2>&1 &
編集が完了したら、以下コマンドでサービスを起動する
root@vcf-cb01 [ /home/admin ]# systemctl start imaging
以下コマンドでサービスが正常に起動(running)している事を確認する
root@vcf-cb01 [ /home/admin ]# systemctl status imaging
以下のコマンドを実行し、imagingサービスが"Dlog4j2.formatMsgNoLookups=true" オプションで実行されている事を確認します。
root@vcf-cb01 [ /home/admin ]# ps -ef|grep jar
root 9184 1 26 15:06 ? 00:00:18 /etc/alternatives/jre/bin/java -jar -Dserver.port=8445 -Dlog4j2.formatMsgNoLookups=true -Dspring.config.additional-location=/opt/vmware/evorack-imaging/config/via.properties,/opt/vmware/evorack-imaging/config/via-db-ext.properties -Dserver.servlet.context-path=/via /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar
root 9654 8756 32 15:07 ? 00:00:16 /etc/alternatives/jre/bin/java -jar -Dserver.port=8081 -Dlog4j2.formatMsgNoLookups=true -Dspring.config.additional-location=/opt/vmware/evorack-imaging/config/via-db-ext.properties /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar
root 10087 4157 0 15:08 pts/0 00:00:00 grep --color=auto jar
Cloud Builder CVE-2021-45046のworkaround
Cloud BuilderにSSHで接続する
suコマンドでrootに昇格
admin@vcf-cb01 [ ~ ]$ su
imagingサービスを停止する
root@vcf-cb01 [ /home/admin ]# systemctl stop imaging
evorack-imaging-esxi-service jarの脆弱性の対処
テンポラリのディレクトリを作成する
root@vcf-cb01 [ /home/admin ]# mktemp -d -t log4j-XXXXXXXXXX
出力例
root@vcf-cb01 [ /home/admin ]# mktemp -d -t log4j-XXXXXXXXXX
/tmp/log4j-TChoNYNPvH
以下のコマンドを実行しlog4j-coreがjarファイルevorack-imaging-esxi-service-0.0.1-SNAPSHOT.jarに存在するかどうかを確認します。
root@vcf-cb01 [ /home/admin ]# zipinfo -1 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar" | grep log4j-core-*
出力例
root@vcf-cb01 [ /home/admin ]# zipinfo -1 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar" | grep log4j-core-*
BOOT-INF/lib/log4j-core-2.13.1.jar
mktempで作成したディレクトリのパスをコピーし、以下コマンドを実行します。
root@vcf-cb01 [ /home/admin ]# unzip "/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar" "BOOT-INF/lib/log4j-core-2.13.1.jar" -d "/tmp/log4j-TChoNYNPvH"
以下のコマンドを実行します。
root@vcf-cb01 [ /home/admin ]# zipinfo -l /tmp/log4j-TChoNYNPvH/BOOT-INF/lib/log4j-core-2.13.1.jar | grep -q "org/apache/logging/log4j/core/lookup/JndiLookup.class"
次に以下のコマンドを実行します。
root@vcf-cb01 [ /home/admin ]# echo $?
戻り値が1の場合は、これ以上の対処が不要なので、via.jarの対処に進む
戻り値が0の場合は、JndiLookup.classが存在するため、続けて以下コマンドを実行する必要があります。
root@vcf-cb01 [ /home/admin ]# zip -q -d "/tmp/log4j-TChoNYNPvH/BOOT-INF/lib/log4j-core-2.13.1.jar" "org/apache/logging/log4j/core/lookup/JndiLookup.class"
これにより、log4j-core-2.1.3.1.jarからJndiLookup.classファイルが削除されます。
変更したlog4j-coreでevorack-imaging jarを更新します。
root@vcf-cb01 [ /home/admin ]# cd "/tmp/log4j-TChoNYNPvH" && zip -ur -0 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar"
出力例
root@vcf-cb01 [ /home/admin ]# cd "/tmp/log4j-TChoNYNPvH" && zip -ur -0 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar"
updating: BOOT-INF/ (stored 0%)
updating: BOOT-INF/lib/ (stored 0%)
updating: BOOT-INF/lib/log4j-core-2.13.1.jar (stored 0%)
via.jarの脆弱性の対処
テンポラリのディレクトリを作成する
root@vcf-cb01 [ /home/admin ]# mktemp -d -t log4j-XXXXXXXXXX
出力例
root@vcf-cb01 [ /home/admin ]# mktemp -d -t log4j-XXXXXXXXXX
/tmp/log4j-ZjZ9Z0Itul
以下のコマンドを実行しlog4j-coreがvia.jarファイルに存在するかどうか確認します
root@vcf-cb01 [ /home/admin ]# zipinfo -1 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar" | grep log4j-core-*
出力例
root@vcf-cb01 [ /home/admin ]# zipinfo -1 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar" | grep log4j-core-*
BOOT-INF/lib/log4j-core-2.13.1.jar
mktempで作成したディレクトリのパスをコピーし、以下コマンドを実行します。
root@vcf-cb01 [ /home/admin ]# unzip "/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar" "BOOT-INF/lib/log4j-core-2.13.1.jar" -d "/tmp/log4j-ZjZ9Z0Itul"
root@vcf-cb01 [ /home/admin ]# zipinfo -l /tmp/log4j-ZjZ9Z0Itul/BOOT-INF/lib/log4j-core-2.13.1.jar | grep -q "org/apache/logging/log4j/core/lookup/JndiLookup.class"
以下のコマンドを実行します。
root@vcf-cb01 [ /home/admin ]# echo $?
戻り値が1の場合は、これ以上の対処が不要なので、imaging serviceを起動する
戻り値が0の場合は、JndiLookup.classが存在するため、続けて以下コマンドを実行する必要があります。
root@vcf-cb01 [ /home/admin ]# zip -q -d "/tmp/log4j-ZjZ9Z0Itul/BOOT-INF/lib/log4j-core-2.13.1.jar" "org/apache/logging/log4j/core/lookup/JndiLookup.class"
これにより、log4j-core-2.1.3.1.jarからJndiLookup.classファイルが削除されます。
変更したlog4j-coreでvia.jarを更新します。
root@vcf-cb01 [ /home/admin ]# cd "/tmp/log4j-ZjZ9Z0Itul" && zip -ur -0 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar"
出力例
root@vcf-cb01 [ /home/admin ]# cd "/tmp/log4j-ZjZ9Z0Itul" && zip -ur -0 "/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar"
updating: BOOT-INF/ (stored 0%)
updating: BOOT-INF/lib/ (stored 0%)
updating: BOOT-INF/lib/log4j-core-2.13.1.jar (stored 0%)
imagingサービスを起動する
root@vcf-cb01 [ /tmp/log4j-ZjZ9Z0Itul ]# systemctl start imaging
スクリプトによる回避策の実行(VMware推奨)
本スクリプトはCVE-2021-44228とCVE-2021-45046に対処可能
既にCVE-2021-44228のworkaroundを実施済みでスクリプトを実行する事を推奨
KBに添付されている「log4j_via_v3.sh」というスクリプトファイルをダウンロードし、Cloud Builderの/home/adminディレクトリにコピーします。
Cloud BuilderにSSHで接続します
suコマンドでrootに昇格
admin@vcf-cb01 [ ~ ]$ su
以下のコマンドでスクリプトを実行します
出力例
root@vcf-cb01 [ /home/admin ]# bash log4j_via_v3.sh
» Starting to remediate log4j issue in imaging service.
» ---
» Stopping imaging service: [systemctl stop imaging]
» ---
» Stage 1 - Entering remediation stage.
» Step 1 - Remove JndiLookup class for CVE-2021-45046. Scanning if any of imaging jars [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar] exist in system.
» Found imaging jar [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar] that needs analysis for existence of JndiLookup class.
» Creating a working directory [/tmp/log4j-MxSOaIPnKF]
» Successfully created working directory [/tmp/log4j-MxSOaIPnKF] for updating [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar]
» Looking for [log4j-core-*] in [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar]
» Executing: [(zipinfo -1 /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar | grep log4j-core-*) || exit 1]
» Extracting [BOOT-INF/lib/log4j-core-2.13.1.jar] from [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar] to temp directory [/tmp/log4j-MxSOaIPnKF]
» Executing: [unzip /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar BOOT-INF/lib/log4j-core-2.13.1.jar -d /tmp/log4j-MxSOaIPnKF || exit 1]
Archive: /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar
extracting: /tmp/log4j-MxSOaIPnKF/BOOT-INF/lib/log4j-core-2.13.1.jar
» Scanning [/tmp/log4j-MxSOaIPnKF/BOOT-INF/lib/log4j-core-2.13.1.jar] to check if [org/apache/logging/log4j/core/lookup/JndiLookup.class] exists.
» Executing: [zipinfo -1 /tmp/log4j-MxSOaIPnKF/BOOT-INF/lib/log4j-core-2.13.1.jar | grep -q org/apache/logging/log4j/core/lookup/JndiLookup.class]
» Scanning completed. [/tmp/log4j-MxSOaIPnKF/BOOT-INF/lib/log4j-core-2.13.1.jar] does not have the affected class. No clean-up needed.
» Cleaning up working directory [/tmp/log4j-MxSOaIPnKF]
» Cleaned up working directory [/tmp/log4j-MxSOaIPnKF]
» ---
» Found imaging jar [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar] that needs analysis for existence of JndiLookup class.
» Creating a working directory [/tmp/log4j-sFS5k5n2D2]
» Successfully created working directory [/tmp/log4j-sFS5k5n2D2] for updating [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar]
» Looking for [log4j-core-*] in [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar]
» Executing: [(zipinfo -1 /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar | grep log4j-core-*) || exit 1]
» Extracting [BOOT-INF/lib/log4j-core-2.13.1.jar] from [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar] to temp directory [/tmp/log4j-sFS5k5n2D2]
» Executing: [unzip /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar BOOT-INF/lib/log4j-core-2.13.1.jar -d /tmp/log4j-sFS5k5n2D2 || exit 1]
Archive: /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar
extracting: /tmp/log4j-sFS5k5n2D2/BOOT-INF/lib/log4j-core-2.13.1.jar
» Scanning [/tmp/log4j-sFS5k5n2D2/BOOT-INF/lib/log4j-core-2.13.1.jar] to check if [org/apache/logging/log4j/core/lookup/JndiLookup.class] exists.
» Executing: [zipinfo -1 /tmp/log4j-sFS5k5n2D2/BOOT-INF/lib/log4j-core-2.13.1.jar | grep -q org/apache/logging/log4j/core/lookup/JndiLookup.class]
» Scanning completed. [/tmp/log4j-sFS5k5n2D2/BOOT-INF/lib/log4j-core-2.13.1.jar] does not have the affected class. No clean-up needed.
» Cleaning up working directory [/tmp/log4j-sFS5k5n2D2]
» Cleaned up working directory [/tmp/log4j-sFS5k5n2D2]
» ---
» Remediation successful for CVE-2021-45046.
» Step 2 - Add flag [-Dlog4j2.formatMsgNoLookups=true] to imaging service start scripts for CVE-2021-44228.
» Check if backup of [/opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh] exists
» Backup file already exists under /opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh.orig
» File [/opt/vmware/evorack-imaging/imaging-util-scripts/start-parent-imaging-service.sh] already contains [-jar -Dserver.port=$VIA_SERVICE_PORT -Dlog4j2.formatMsgNoLookups=true]. No file updates necessary.
» Check if backup of [/opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.sh] exists.
» Backup file already exists under [/opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.sh.orig]
» File [/opt/vmware/evorack-imaging/imaging-util-scripts/start-imaging-services.sh] already contains [-jar -Dserver.port=$SECOND -Dlog4j2.formatMsgNoLookups=true]. No file updates necessary.
» Starting imaging service: systemctl start imaging
» ---
» Remediation successful for CVE-2021-44228.
» Stage 2 - Entering verification stage.
» Step 1 - Verification of remediation for CVE-2021-45046.
» Verifying classpath removal.
» Making sure JndiLookup class [org/apache/logging/log4j/core/lookup/JndiLookup.class] shouldn't exist in imaging jar [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar]
» Creating a working directory [/tmp/log4j-qoy12HBnND]
» Successfully created working directory [/tmp/log4j-qoy12HBnND] for updating [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar]
» Looking for [log4j-core-*] in [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar]
» Executing: [(zipinfo -1 /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar | grep log4j-core-*) || exit 1]
» Extracting [BOOT-INF/lib/log4j-core-2.13.1.jar] from [/opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar] to temp directory [/tmp/log4j-qoy12HBnND]
» Executing: [unzip /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar BOOT-INF/lib/log4j-core-2.13.1.jar -d /tmp/log4j-qoy12HBnND || exit 1]
Archive: /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar
extracting: /tmp/log4j-qoy12HBnND/BOOT-INF/lib/log4j-core-2.13.1.jar
» Scanning [/tmp/log4j-qoy12HBnND/BOOT-INF/lib/log4j-core-2.13.1.jar] to check if [org/apache/logging/log4j/core/lookup/JndiLookup.class] exists.
» Executing: [zipinfo -1 /tmp/log4j-qoy12HBnND/BOOT-INF/lib/log4j-core-2.13.1.jar | grep -q org/apache/logging/log4j/core/lookup/JndiLookup.class]
» ---
» Scanning completed.
» Verified [/tmp/log4j-qoy12HBnND/BOOT-INF/lib/log4j-core-2.13.1.jar] does not have the affected class.
» ---
» Cleaning up working directory [/tmp/log4j-qoy12HBnND]
» Cleaned up working directory [/tmp/log4j-qoy12HBnND]
» ---
» Making sure JndiLookup class [org/apache/logging/log4j/core/lookup/JndiLookup.class] shouldn't exist in imaging jar [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar]
» Creating a working directory [/tmp/log4j-eDdiOOpPJf]
» Successfully created working directory [/tmp/log4j-eDdiOOpPJf] for updating [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar]
» Looking for [log4j-core-*] in [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar]
» Executing: [(zipinfo -1 /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar | grep log4j-core-*) || exit 1]
» Extracting [BOOT-INF/lib/log4j-core-2.13.1.jar] from [/opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar] to temp directory [/tmp/log4j-eDdiOOpPJf]
» Executing: [unzip /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar BOOT-INF/lib/log4j-core-2.13.1.jar -d /tmp/log4j-eDdiOOpPJf || exit 1]
Archive: /opt/vmware/evorack-imaging/services/evorack-imaging-services/via.jar
extracting: /tmp/log4j-eDdiOOpPJf/BOOT-INF/lib/log4j-core-2.13.1.jar
» Scanning [/tmp/log4j-eDdiOOpPJf/BOOT-INF/lib/log4j-core-2.13.1.jar] to check if [org/apache/logging/log4j/core/lookup/JndiLookup.class] exists.
» Executing: [zipinfo -1 /tmp/log4j-eDdiOOpPJf/BOOT-INF/lib/log4j-core-2.13.1.jar | grep -q org/apache/logging/log4j/core/lookup/JndiLookup.class]
» ---
» Scanning completed.
» Verified [/tmp/log4j-eDdiOOpPJf/BOOT-INF/lib/log4j-core-2.13.1.jar] does not have the affected class.
» ---
» Cleaning up working directory [/tmp/log4j-eDdiOOpPJf]
» Cleaned up working directory [/tmp/log4j-eDdiOOpPJf]
» ---
» Verification steps for CVE-2021-45046 completed.
» Step 2 - Verification of remediation for CVE-2021-44228.
» Checking if imaging service is active.
» Executing: [systemctl status imaging || exit 1]
» Monitoring if imaging service is started.
» Imaging service started successfully.
» Checking if imaging jars are updated with [-Dlog4j2.formatMsgNoLookups=true]
» Executing: [ps -ef|grep jar || exit 1]
» Reading the output of the command [ps -ef | grep jar] line by line.
» Scanning if [via] or [evorack-imaging-esxi-service] services is in the following line:
» [root 15767 15736 0 04:21 ? 00:00:00 /etc/alternatives/jre/bin/java -jar -Dserver.port=8081 -Dlog4j2.formatMsgNoLookups=true -Dspring.config.additional-location=/opt/vmware/evorack-imaging/config/via-db-ext.properties /opt/vmware/evorack-imaging/services/evorack-imaging-services/evorack-imaging-esxi-service-0.0.1-SNAPSHOT.jar]
» Verifying the service has the flag [-Dlog4j2.formatMsgNoLookups=true]
» Verified flag [-Dlog4j2.formatMsgNoLookups=true] is present.
» Scanning if [via] or [evorack-imaging-esxi-service] services is in the following line:
» [root 15784 15782 0 04:21 pts/0 00:00:00 grep jar]
» Verification steps for CVE-2021-44228 completed.
» Completed script execution.
SDDC Manager
本回避策はVCF 3.x(VCF 3.10.2, 3.10.2.1と3.10.2.2を除く)と4.xのCloud Builderに適応可能です。
SDDC Managerにvcfユーザーで接続する。
suコマンドでrootに昇格
vcf@vcf-sddcmgr [ ~ ]$ su
以下のファイルを編集する前にバックアップを取得しておく
/usr/local/vip/bin/start-vip.sh
root@vcf-sddcmgr [ /home/vcf ]# cp /usr/local/vip/bin/start-vip.sh /usr/local/vip/bin/start-vip.sh.orig
/usr/local/vip/bin/start-vip.shを編集する
root@vcf-sddcmgr [ /home/vcf ]# vi /usr/local/vip/bin/start-vip.sh
Before
nohup $JAVA -jar -Dapp.log.home=/var/log/vmware/vip -server -XX:MaxMetaspaceSize=64m -XX:ParallelGCThreads=2 -Djava.compiler=NONE $1 --vipservice.cross.domain.alloworigin=$(hostname) --server.scheme=http --server.http.port=7900> $2 2>&1 &
After
nohup $JAVA -jar -Dapp.log.home=/var/log/vmware/vip -server -XX:MaxMetaspaceSize=64m -XX:ParallelGCThreads=2 -Djava.compiler=NONE -DLOG4J_FORMAT_MSG_NO_LOOKUPS=true $1 --vipservice.cross.domain.alloworigin=$(hostname) --server.scheme=http --server.http.port=7900> $2 2>&1 &
編集が完了したら、以下コマンドでサービスを再起動する
root@vcf-sddcmgr [ /home/vcf ]# systemctl restart vip-manager-i18n.service
以下コマンドを実行しVIP Manager Serviceが- DLOG4J_FORMAT_MSG_NO_LOOKUPS=trueオプションで実行されている事を確認します。
root@vcf-sddcmgr [ /home/vcf ]# systemctl status vip-manager-i18n.service
* vip-manager-i18n.service - VMware Internationalization Service
Loaded: loaded (/etc/systemd/system/vip-manager-i18n.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-12-24 06:14:20 UTC; 3min 13s ago
Process: 2664 ExecStop=/usr/local/vip/bin/init.sh stop (code=exited, status=0/SUCCESS)
Process: 2684 ExecStart=/usr/local/vip/bin/init.sh start (code=exited, status=0/SUCCESS)
Main PID: 2714 (java)
Tasks: 26 (limit: 19197)
Memory: 207.8M
CGroup: /system.slice/vip-manager-i18n.service
`-2714 /usr/bin/java -jar -Dapp.log.home=/var/log/vmware/vip -server -XX:MaxMetaspaceSize=64m -XX:ParallelGCThreads=2 -Djava.compiler=NONE -DLOG4J_FORMAT_MSG_NO_LOOKUPS=true /usr/local/vip/vip-...Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: start VIP service
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: execute start function
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: executing: /usr/local/vip/bin/start-vip.sh /usr/local/vip/vip-manager-i18n-common.jar /usr/local/vip/work/vip-runtime.log /usr/local/vip/work
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: =====startup vip=====
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: found java home: /etc/alternatives/jre
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: run vip from: /usr/local/vip/vip-manager-i18n-common.jar
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: log file: /var/log/vmware/vip/vip-runtime.log
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: vip service is started!
Dec 24 06:14:20 vcf-sddcmgr.vcf.local init.sh[2684]: end of starting VIP service
Dec 24 06:14:20 vcf-sddcmgr.vcf.local systemd[1]: Started VMware Internationalization Service.
CVE-2021-45046のworkaround
本回避策はVCF 3.x(VCF 3.10.2, 3.10.2.1と3.10.2.2を除く)と4.xのCloud Builderに適応可能です。
vip manager i18nサービスを停止する
root@vcf-sddcmgr [ /home/vcf ]# systemctl stop vip-manager-i18n.service
vip-manager-i18n-common.jarの脆弱性の対処
テンポラリのディレクトリを作成する
root@vcf-sddcmgr [ /home/vcf ]# mktemp -d -t log4j-XXXXXXXXXX
出力例
root@vcf-sddcmgr [ /home/vcf ]# mktemp -d -t log4j-XXXXXXXXXX
/tmp/log4j-t01QRNHQSX
以下のコマンドを実行しlog4j-coreがvip-manager-i18n-common.jaファイルに存在するかどうか確認します
root@vcf-sddcmgr [ /home/vcf ]# zipinfo -1 "/usr/local/vip/vip-manager-i18n-common.jar" | grep log4j-core-*
出力例
root@vcf-sddcmgr [ /home/vcf ]# zipinfo -1 "/usr/local/vip/vip-manager-i18n-common.jar" | grep log4j-core-*
BOOT-INF/lib/log4j-core-2.13.3.jar
mktempで作成したディレクトリのパスをコピーし、以下コマンドを実行します。
root@vcf-sddcmgr [ /home/vcf ]# unzip "/usr/local/vip/vip-manager-i18n-common.jar" "BOOT-INF/lib/log4j-core-2.13.3.jar" -d "/tmp/log4j-t01QRNHQSX"
root@vcf-sddcmgr [ /home/vcf ]# zipinfo -1 /tmp/log4j-t01QRNHQSX/BOOT-INF/lib/log4j-core-2.13.3.jar | grep -q "org/apache/logging/log4j/core/lookup/JndiLookup.class"
以下のコマンドを実行します。
root@vcf-sddcmgr [ /home/vcf ]# echo $?
戻り値が1の場合は、これ以上の対処が不要なので、vip manager serviceの起動に進む
戻り値が0の場合は、JndiLookup.classが存在するため、続けて以下コマンドを実行する必要があります。
root@vcf-sddcmgr [ /home/vcf ]# zip -q -d "/tmp/log4j-t01QRNHQSX/BOOT-INF/lib/log4j-core-2.13.3.jar" "org/apache/logging/log4j/core/lookup/JndiLookup.class"
これにより、log4j-core-2.13.3.jarからJndiLookup.classファイルが削除されます。
変更したlog4j-coreでvia.jarを更新します。
root@vcf-sddcmgr [ /home/vcf ]# cd "/tmp/log4j-t01QRNHQSX/" && zip -ur -0
出力例
root@vcf-sddcmgr [ /home/vcf ]# cd "/tmp/log4j-t01QRNHQSX/" && zip -ur -0 "/usr/local/vip/vip-manager-i18n-common.jar"
updating: BOOT-INF/ (stored 0%)
updating: BOOT-INF/lib/ (stored 0%)
updating: BOOT-INF/lib/log4j-core-2.13.3.jar (stored 0%)
vip manager i18nサービスを起動します。
root@vcf-sddcmgr [ /tmp/log4j-t01QRNHQSX ]# systemctl start vip-manager-i18n.service
スクリプトによる回避策の実行(VMware推奨)
本スクリプトはCVE-2021-44228とCVE-2021-45046に対処可能
既にCVE-2021-44228のworkaroundを実施済みでスクリプトを実行する事を推奨
KBに添付されている「 log4j_vip_v3」というスクリプトファイルをダウンロードし、SDDC Managerの/home/vcf ディレクトリにコピーします。
SDDC ManagerにSSHで接続します
suコマンドでrootに昇格
vcf@vcf-sddcmgr [ ~ ]$ su
以下のコマンドでスクリプトを実行します
出力例
root@vcf-sddcmgr [ /home/vcf ]# bash log4j_vip_v3.sh
» Starting to remediate log4j issue in VIP service
» ---
» Stopping VIP service: [systemctl stop vip-manager-i18n.service]
» ---
» Step 1 - Scanning if any of VIP jars [/usr/local/vip/vip-manager-i18n-common.jar /usr/local/vip/vip-manager-i18n-lite-master.0.0.276.jar] exist in system
» Found VIP jar [/usr/local/vip/vip-manager-i18n-common.jar] that needs analysis for existence of JndiLookup class
» Creating a working directory [/tmp/log4j-Q952zriuhN]
» Successfully created working directory [/tmp/log4j-Q952zriuhN] for updating [/usr/local/vip/vip-manager-i18n-common.jar]
» Looking for [log4j-core-*] in [/usr/local/vip/vip-manager-i18n-common.jar]
» Executing: [(zipinfo -1 /usr/local/vip/vip-manager-i18n-common.jar | grep log4j-core-*) || exit 1]
» Extracting [BOOT-INF/lib/log4j-core-2.13.3.jar] from [/usr/local/vip/vip-manager-i18n-common.jar] to temp directory [/tmp/log4j-Q952zriuhN]
» Executing: [unzip /usr/local/vip/vip-manager-i18n-common.jar BOOT-INF/lib/log4j-core-2.13.3.jar -d /tmp/log4j-Q952zriuhN || exit 1]
Archive: /usr/local/vip/vip-manager-i18n-common.jar
extracting: /tmp/log4j-Q952zriuhN/BOOT-INF/lib/log4j-core-2.13.3.jar
» Scanning [/tmp/log4j-Q952zriuhN/BOOT-INF/lib/log4j-core-2.13.3.jar] to check if [org/apache/logging/log4j/core/lookup/JndiLookup.class] exists
» Executing: [zipinfo -1 /tmp/log4j-Q952zriuhN/BOOT-INF/lib/log4j-core-2.13.3.jar | grep -q org/apache/logging/log4j/core/lookup/JndiLookup.class]
» Scanning completed. [/tmp/log4j-Q952zriuhN/BOOT-INF/lib/log4j-core-2.13.3.jar] does not have the affected class. No clean-up needed.
» Cleaning up working directory [/tmp/log4j-Q952zriuhN]
» Cleaned up working directory [/tmp/log4j-Q952zriuhN]
» ---
» Step 2 - Update flag [DLOG4J_FORMAT_MSG_NO_LOOKUPS=true] in VIP service start script
» Checking if flag [DLOG4J_FORMAT_MSG_NO_LOOKUPS=true] is set in [/usr/local/vip/bin/start-vip.sh] already
» Executing: [grep -q DLOG4J_FORMAT_MSG_NO_LOOKUPS=true /usr/local/vip/bin/start-vip.sh]
» Flag [DLOG4J_FORMAT_MSG_NO_LOOKUPS=true] is already set in VIP service start file [/usr/local/vip/bin/start-vip.sh]. No further action needed...
» ---
» Starting VIP service: systemctl start vip-manager-i18n.service
» ---
» Step 3 - Entering verification stage
» Verifying classpath removal
» Verifying JndiLookup class [org/apache/logging/log4j/core/lookup/JndiLookup.class] doesn't exist in VIP jar [/usr/local/vip/vip-manager-i18n-common.jar]
» Creating a working directory [/tmp/log4j-YYgTDfZNXJ]
» Successfully created working directory [/tmp/log4j-YYgTDfZNXJ] for updating [/usr/local/vip/vip-manager-i18n-common.jar]
» Looking for [log4j-core-*] in [/usr/local/vip/vip-manager-i18n-common.jar]
» Executing: [(zipinfo -1 /usr/local/vip/vip-manager-i18n-common.jar | grep log4j-core-*) || exit 1]
» Extracting [BOOT-INF/lib/log4j-core-2.13.3.jar] from [/usr/local/vip/vip-manager-i18n-common.jar] to temp directory [/tmp/log4j-YYgTDfZNXJ]
» Executing: [unzip /usr/local/vip/vip-manager-i18n-common.jar BOOT-INF/lib/log4j-core-2.13.3.jar -d /tmp/log4j-YYgTDfZNXJ || exit 1]
Archive: /usr/local/vip/vip-manager-i18n-common.jar
extracting: /tmp/log4j-YYgTDfZNXJ/BOOT-INF/lib/log4j-core-2.13.3.jar
» Scanning [/tmp/log4j-YYgTDfZNXJ/BOOT-INF/lib/log4j-core-2.13.3.jar] to check if [org/apache/logging/log4j/core/lookup/JndiLookup.class] exists
» Executing: [zipinfo -1 /tmp/log4j-YYgTDfZNXJ/BOOT-INF/lib/log4j-core-2.13.3.jar | grep -q org/apache/logging/log4j/core/lookup/JndiLookup.class]
» ---
» Scanning completed.
» Verified [/tmp/log4j-YYgTDfZNXJ/BOOT-INF/lib/log4j-core-2.13.3.jar] does not have the affected class.
» ---
» Cleaning up working directory [/tmp/log4j-YYgTDfZNXJ]
» Cleaned up working directory [/tmp/log4j-YYgTDfZNXJ]
» ---
» Verifying [LOG4J_FORMAT_MSG_NO_LOOKUPS=true] is updated in VIP start script
» Executing: [ps -ef | grep /vip/vip-manager-i18n | grep 'DLOG4J_FORMAT_MSG_NO_LOOKUPS=true']
vcf_vip 3750 1 0 06:50 ? 00:00:00 /usr/bin/java -jar -Dapp.log.home=/var/log/vmware/vip -server -XX:MaxMetaspaceSize=64m -XX:ParallelGCThreads=2 -Djava.compiler=NONE -DLOG4J_FORMAT_MSG_NO_LOOKUPS=true /usr/local/vip/vip-manager-i18n-common.jar --vipservice.cross.domain.alloworigin=vcf-sddcmgr.vcf.local --server.scheme=http --server.http.port=7900
» ---
» Verified [LOG4J_FORMAT_MSG_NO_LOOKUPS=true] is updated in VIP start script successfully
» Remediation successful for CVE-2021-44228
» ---
» Script run completed.
その他のVCFコンポーネントの対応については、KB 87095を参照してください。
以上です。
vRealize Automation 8.1から8.2へのアップデート
先日デプロイしたvRA8.1環境を8.2へアップグレードします。途中で何度か躓いたので、その備忘録として残しておきます。
vRAのアップグレードは主に以下の順序で行います。
- vRSLCMを8.1から8.2へアップデート
- vRA 8.1から8.2へアップデート
それでは、アップグレードを実施します。
"Lifecycle Operations"をクリック
"Settings"をクリック
"System Upgrade"をクリック
今回アップデートにisoファイル(VMware-vLCM-Appliance-8.2.0.23-16982087-updaterepo.iso)を使用しますので、"Select Repository Type" > "CD-ROM"を選択し、"CHECK FOR UPGRADE"をクリック
ターゲットバージョンの8.2.0.23が検知されました。
実行前にvRSLCMのSnapshotを取得しておきましょう。
vCenterのホストネームを入力し、Credentialを選択
"SUBMIT"をクリック
Snapshotのリクエストが完了するのを待ちます。
"UPGRADE"をクリックして実行します。
インストールが実行されています。
アップデート完了すると自動で再起動されますので、完了まで待ちます。
アップデート後のバージョンは以下から確認可能です。
"Lifecycle Operations" > "Settings" > "System Details"
vRAをアップデートする前にvIDMを互換性のあるバージョンにアップデートする必要がありますが、私の環境ではvIDMは3.3.2でvRA8.2と互換性がありますので、今回vIDMのアップデートは不要です。
まず事前に、My VMwareからvRAのアップデートisoファイル(Prelude_VA-8.2.0.12959-17018654-updaterepo.iso)をダウンロードします。
ダウンロード後、vRSLCMの"/data/"配下にコピーします。(今回は(/data/binaries/OVAに配置)
それでは、vRSLCMからアップグレードしていきます。
"Lifecycle Operations" > "Settings" > "Binary Mapping"
"ADD BINARIES"をクリック
Location TypeにLocalを選択、Base Locationはisoファイルへのパス(/data/binaries/OVA)を入力し、"ADD"をクリック
躓きポイント①
エラーが検知されました。
Error Code: LCMSOURCEMAPPING10018
Selected files checksums does not match with any product versions supported by vRealize Lifecycle Manager.
One or more selected files checksums does not match with any product versions supported by vRealize Lifecycle Manager.
エラーコードを調べた所、これに合致している模様です。
Solved: vRA 8.1 / LCM 8.1 - error when source mapping vRA ... - VMware Technology Network VMTN
vRSLCMへパッチを適用する必要がありますので、vRAのアップデートは一旦中断します。
"Settings > Binary Mapping" > "Patch Binaries"タブ > "ADD PATCH BINARY"
Request Detailsから進捗を確認し、完了するのを待ちます。
"Settings > "Binary Mapping" > "Patch Binaries"タブでvRSLCMのpatchが表示されている事を確認します。
"Settings > "System Patches"
"NEW PATCH"をクリック
"NEXT"をクリック
"INSTALL"
PATCH適用完了まで待ちます。
バージョンは以下から確認可能です。
"Lifecycle Operations" > "Settings" > "System Details"
vRSLCMのパッチが適用できた所で、再度vRAのアップデートを試します。
PATCH1適用後はPassしました。
"Binary Mapping" > "Product Binaries"に表示されている事を確認します。
それでは、vRAのアップデートを再開します。
"Environments" > "vRAのEnvironment"を選択
"UPGRADE"をクリックします。
vRSLCMの管理外でvRAに対して何かしら変更が加わった場合は、アップデートが失敗する可能性がありますので、アップデート実行前にvRSLCMとインベントリ情報を同期しておきます。
"TRIGGER INVENTORY SYNC"をクリック
"SUBMIT"をクリック
Request DetailsでStatusがSuccessfulになる事を確認します。
それでは、アップグレードに進みます。
"PEOCEED"をクリック
"NEXT"をクリック
"RUN PRECHECK"をクリック
躓きポイント②
Pre-checkでエラーになりました。
エラーの詳細を確認するために、"View"をクリックして見てみます。
VMware KB#79925を参照せよと記載があります。
https://kb.vmware.com/s/article/79925
Disk3上のservices-logsパーティション(/services-logs)の容量が不足している事が原因のようです。容量を拡張する必要がありますので、実施していきます。
vRAが稼働するESXiホストのホストクライアントにアクセスします。
https://ESXi ip or hostname/ui
vRAの仮想アプライアンスを右クリック > "設定の編集" > ハードディスク3を8GB > 25GBに変更します。
以下、Workaroundに記載のあるコマンドを実行します。
WorkaroundTo work around this issue in version 8.1 and earlier:
- SSH to the appliance.
- Run the command: "vracli disk-mgr resize". The resize procedure will start in up to a minute. Progress could be monitored in the /var/log/disk_resize.log. It is expected to fail while resizing file system for logs disk.
- Run the command: "/usr/sbin/resize2fs /dev/mapper/logs_vg-services--logs"
- Run the command:
- For vRA/vRO 8.0: "rm /var/run/disk_stats"
- For vRA/vRO 8.0.1 and 8.1: "rm /var/vmware/prelude/disk-management/disk_stats"
- Run the command "vracli disk-mgr" to verify if new disk space is visible.
コマンド実行履歴です。
root@vra [ ~ ]# vracli disk-mgr resize
2021-06-07 07:31:47,891 [INFO] Resetting automatic resize scan schedule...
2021-06-07 07:31:47,891 [INFO] Reset successful. Automatic resize of any device where it is applicable will commence in the next minute.
root@vra [ ~ ]# /usr/sbin/resize2fs /dev/mapper/logs_vg-services--logs
resize2fs 1.43.4 (31-Jan-2017)
Filesystem at /dev/mapper/logs_vg-services--logs is mounted on /services-logs; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mapper/logs_vg-services--logs is now 6552576 (4k) blocks long.root@vra [ ~ ]# rm /var/vmware/prelude/disk-management/disk_stats
root@vra [ ~ ]# vracli disk-mgr
/dev/sda4(/):
Total size: 47.86GiB
Free: 41.25GiB(86.2%)
Available(for non-superusers): 38.81GiB(81.1%)
/dev/sdb(/data):
Total size: 140.74GiB
Free: 107.41GiB(76.3%)
Available(for non-superusers): 100.21GiB(71.2%)
/dev/sdc(/services-logs):
Total size: 24.54GiB
Free: 24.23GiB(98.7%)
Available(for non-superusers): 23.15GiB(94.3%)
/dev/sdd(/metrics):
Total size: 19.56GiB
Free: 19.31GiB(98.8%)
Available(for non-superusers): 18.31GiB(93.6%)
"RE-RUN PRECHECK"をクリック
Pre-checkもpassしましたので、"NEXT"をクリック
"SUBMIT"をクリック
Request Detailsから進捗を確認可能
アップグレードが完了しました。私の環境だと約1時間弱程かかりました。
"Environments" > "vRAのEnvironment"からvRAが8.2へアップグレードされいる事を確認可能です。
以上です。
アップデートは一筋縄ではいきませんでしたが、本記事が何かしらのお役に立てれば幸いです。
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
最後は、vRealize Orchestrator(vRO)についてです。
vROで様々なタスクやプロセスを組み合わせたワークフローを作成する事によって、簡単に処理の自動化を行う事が可能になります。また、VMware環境だけでなく、3rd Party製品のプラグインをインストールする事によって、システム全体を自動化するプラットフォームとして利用する事ができます。
今回、ワークフローの作成は行いませんが、事前準備として、vCenterとの連携を行います。しかしその過程で、vCenterのインベントリ情報が正しく認識できない事象が発生し、その対処としてvROのプラグインの更新を行いましたので、その手順についても紹介します。
それでは、vROとvCenterとの連携を行います。
vRA "My Services" > "Orchestrator"
"Workflows" > Filterで"Add a vcenter"で検索
"Set the vCenter Server instance properties"タブで必要情報を入力
"Set the connection properties"タブで必要情報を入力
- Do you want to use a session per user method~ のチェックはOffにします。
- vCenter Serverインスタンスへの接続に使用するユーザー名とパスワード
"Additional Endpoints"は"Set the vCenter Server instance properties"タブで入力した
vCenterのIP or ホストネームが自動で入力されます。
"RUN"をクリックし、Statusが"Completed"になる事を確認します。
vCenterと正しく連携できたか確認してみます。
"Administration" > "Inventory"
正しくvCenterと連携ができていません。
この状態ですと、vROからvCenterに対してワークフローが実行できません。
プラグインのバージョンが古いと、このような状態になる場合がありますので、まずは最新バージョンのプラグインをインストールします。
vROの管理インターフェースにログインします。
rootユーザーでログイン
"プラグインを管理"をクリック
プラグインのバージョンを確認します。
現在のバージョンは6.5.0.15718902であることがわかります。
vRO vCenter Server plug-in for vSphere 7.0 service... - VMware Technology Network VMTN
Version7.0.0-18048864がリリースされていましたので、こちらをインストールします。
Version 7.0.0-18048864 (built 2021-05-19)
"Attachments"から、o11nplugin-vsphere-7.0.0-18048864.vmoapp.zipをローカルにダウンロードします。
ダウンロードが完了したら、zipファイルを解凍します。
フォルダの中に"o11nplugin-vsphere.dar"というファイルを使用します。
"参照"から選択
"アップロード"をクリック
"インストール"をクリック
プラグインのインストールが実行されました。
数分経過後、再度プラグインのバージョン画面を確認します。
7.0.0-18048864に更新されています。
vCenterのプラグインの更新ができましたので、正しく表示されていなかったインベントリの画面を確認します。正しく表示されていますね。
もし、プラグイン更新後も上記のように正しく表示されない場合は、"Workflows" > Filterにて"Update a vcenter"などで検索し、"RUN"をクリック
"Update a vCenter Server instance"が"Completed"のStatusになる事を確認します。
再度"Administration" > "Inventory"でvCenterのインベントリ情報を確認します。
この後、ワークフローを作成していく流れですが、今後ワークフローの検証を行った際に記載していく予定です。
以上です。
vRealize Automationを構築する Part7: Content & Catalogの展開
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
今回は作成したBlueprintをユーザーに公開します。作成したBlueprintをユーザーに公開するにはService Brokerを設定します。
"My Services" > "Service Broker"
"Content&Policies" > "Content Sources" > "NEW"
"Cloud Assembly Blueprint"を選択します。
名前とSource Projectを選択し、"VALIDATE"をクリック
"Content source validated successfully. 0 items found." となってしまってます。
通常であれば、前回作成したBlueprintが1 itemとして表示されるはずです。
"Cloud Assembly" > "Design" > "VERSION HISTORY"を見てみます。
作成したv1.0の"RELEASE"をクリックしてみます。
"RELEASE"をクリック
v1.0がリリースされました。
再度Validationを実施してみます。
今度は"1 items found"になっていますので、"CREATE & IMPORT"をクリック
作成できました。
"Content Sharing"をクリックし、Projectを指定、"ADD ITEMS"
"Win2016"のチェックボックスにチェックを入れ"SAVE"をクリック
"Content"セクションにtemplateが表示されます。
"Content"セクションには、インポートしたすべてのblueprintとtemplateが表示されます。また、このページの全ての項目は"Catalog"に表示されます。
"Catalog"をクリックするとユーザーがリクエスト可能な項目が表示されます。
適切なアクセス権限を付与されているユーザーは、このページから要求可能です。
"REQUEST" > "SUBMIT"をクリックします。
vSphere Clientからも確認可能です。
DeploymentのTaskがも完了しました。
一度リクエストが送信されると、全て自動でWindows Serverを展開できます。
以上です。
vRealize Automationを構築する Part6: Blueprintの展開
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
Blueprintは仮想マシン、ネットワーク、ストレージ、セキュリティグループなどのリソースをキャンバス上に配置し、パラメータを指定、展開していきます。今回は仮想マシンを1台デプロイする単純なBlueprintを作成して動作を見ていきます。
"Cloud Assembly" > "Design" > "Blueprints" > "NEW"
Blueprintの名前とProject名を指定し、"CREATE"
中央のドットがある部分はキャンバスと呼ばれます。
左側にリソースタイプが表示され、右側に選択したリソースのプロパティが表示されます。
Resource Type > "vSphere" > "Machine" をキャンバスにドラッグします。
vSphere Machine用のNetworkも必要です。
"vSphere" > "Network" をキャンバスにドラッグします。
キャンバス上にvSphere MachineとNetworkを追加しましたので、2つのリソースを接続します。
Machine Resourceを選択し"Properties"タブから"Win2016"にリネームしました。
Imageには、Image Mappingで作成したものを指定しました。
"TEST" を実行し、"Successful"が表示される事を確認します。
デプロイする前に現在のVersionを"v1.0"として管理しておきます。
"DEPLOY"を実行します
デプロイ中の進捗状況は"History"から確認可能です。
vSphere上でもデプロイされている事を確認できます。
以上でBlueprintの展開は終了です。
ここで作成したBlueprintをCatalogに展開する事によって、ユーザーはいつでもWindows Serverの仮想マシンを自動でデプロイする事ができます。
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
今回は、Flavor MappingとImage Mappingを作成していきます。
Flavor Mappingは、特定のクラウドアカウント/リージョンに対するリソースのサイズを定義します。例として以下のようにサイズを定義しBlueprintの作成時に使用します。
- Small (CPU#1/MEM#2GB)
- Medium (CPU#2/MEM#4GB)
- Large (CPU#4/MEM#8GB)
"Infrastructure" > "Configure" > "Flavor Mappings" > "NEW FLAVOR MAPPING"をクリック
Flavor nameを入力
Cloud Accountを選択し、CPUとMemoryの値を入力しCREATE
Flavor Mappingが作成できました。
次はImage Mappingを作成します。
Image Mappingは、OSのテンプレートです。Cloud Accountで用意されているVMテンプレートをImgetとして定義します。
"Infrastructure" > "Configure" > "Image Mappings" > "NEW Image MAPPING"をクリック
Image nameを入力
Cloud Accountを選択し、ImageのためのTemplateを選択します。
今回はWindows Server 2016のTemplateを用意しましたので、そちらを選択します。
Image Mappingが作成できました。
次は、Network Profileを作成します。
Network Profileは、デプロイするVMが接続するネットワークを定義します。
"Infrastructure" > "Configure" > "Network Profiles" > "NEW NETWORK PROFILE"をクリック
"Summary"タブからCloud Accountを指定し、Network Profile名を入力します。
"Networks"タブから"ADD NETWORK"をクリック
選択したCloud Account上の全てのネットワークが表示されます。
VMをデプロイした際に所属させるネットワークを指定します。
"CREATE"をクリックして作成します。
Network Profileが作成できました。
次は作成したNetwork ProfileのIPレンジを指定してみます。
"Infrastructure" > "Resources" > "Networks" > 先ほど選択したネットワークをクリックします。
IPアドレス(CIDR形式)/Default Gateway/DNSの情報を入力
"Default for Zone"にチェックを入れて、"SAVE"をクリックします。
IP Rangeを指定します。
"Infrastructure" > "Resources" > "Networks" > "IP Ranges" > "NEW IP RANGE"
先ほどCIDER形式のIPアドレスやDefault Gatewayなどを指定したネットワークがドロップダウンで表示されます。
IP Rangeに指定するStart IPとEnd IPを入力して、"ADD"をクリックします。
IP Rangeが指定できました。このIPはこれからデプロイするVM用に使用されます。
最後はStorage Profilewを作成します。
Storage Profileは、デプロイするVMに適応するStorage PolicyやDiskのプロビジョニングタイプ(Thin or Thick)などを定義します。
"Infrastructure" > "Configure" > "Storage Profiles" > "NEW STORAGE PROFILE"
Cloud AccountやStorage Profile名を入力しその他は環境に合わせて指定します。
"CREATE"をクリック
Storage Profileが作成できました。
ここまでで、Flavor Mapping、Image Mapping、Network Profile、Storage Profileを作成しました。
以上です。
vRealize Automationを構築する Part4: Projectの作成
今回、vRealize Automation8.1(vRA)を検証する必要がありましたので、デプロイしてテストしてみました。その構築メモになります。
vRealize Automationを構築する Part1: vRAのデプロイ
vRealize Automationを構築する Part2: vIDMの設定
vRealize Automationを構築する Part3: Cloud Account & Cloud Zoneの作成
vRealize Automationを構築する Part4: Projectの作成
vRealize Automationを構築する Part5: Flavor Mapping & Image Mappingの作成
vRealize Automationを構築する Part6: Blueprintの展開
vRealize Automationを構築する Part7: Content & Catalogの展開
vRealize Automationを構築する Part8: vRealize Orchestratorとの連携
今回はProjectを作成です。
前回作成したCloud ZoneとユーザーをこのProjectに割り当てます。
"Infrastructure" > "Configure" > "Projects" > "New Project"をクリック
SummaryタブのProject名を入力します。
"Users"タブをクリックし、ユーザー/グループを追加します。
Add Usersをクリックし、追加するユーザーを選択します。
"Provisioning"タブから"ADD CLOUD ZONE"でCloud Zoneを選択します。
作成したCloud Zoneを選択し、その他のパラメータも確認の上、"ADD"をクリックします。
次は"Custom Naming" > "Template"セクションに移動します。
ここでは、vRAを介してデプロイされるVM名の名前付けパターン/規則を定義します。
その他はデフォルト設定のまま、"CREATE"をクリックします。
Projectが作成できました。
ここまでで、Cloud Account、Cloud ZoneとProjectが作成できました。
以上です。
