こんにちは。AWS CLIが好きな福島です。
- はじめに
- 構成図
- ポイント
- 前提
- ①EFSの構築
- ②EC2へのEFSのマウント[1,2号機]
- ③Radiusサーバへユーザーの追加[1号機]
- ④Google Authenticatorの設定
- ⑤Radiusサーバへユーザーの追加[2号機]
- ⑥動作確認
- 補足
- 終わりに
はじめに
今回は、WorkSpaces環境におけるRadiusサーバの冗長化を EFSを利用して実装する構成について、ブログに記載いたします。
構成図
ポイント
EFSがない場合でも、Radiusサーバの冗長化は可能ですが、 EFSを導入することで運用を軽減することが可能です。
具体的にRadiusサーバにユーザー追加する場合は、以下の運用が必要になるかと存じますが、 EFS導入により、④を省くことが可能です。
運用例
- ①Radiusサーバへユーザーの追加[1号機]
- ②Google Authenticatorの設定[1号機]
- ③Radiusサーバへユーザーの追加[2号機]
- ④Google Authenticatorの設定のコピー[1号機⇒2号機] ※EFS導入により省略可能
- ⑤Q/Rコードの配布
④をコマンドで実行する場合の方法は参考として、末尾に記載しております。
前提
RadiusサーバやWorkSpacesの環境は構築できている前提とします。 Radiusサーバの設定は以下のブログを参考に設定しています。
そのため、本ブログに記載する内容は以下の通りとなります。
- ①EFSの構築
- ②EC2へのEFSのマウント[1,2号機]
- ③Radiusサーバへユーザーの追加[1号機]
- ④Google Authenticatorの設定[1号機]
- ⑤Radiusサーバへユーザーの追加[2号機]
- ⑥動作確認
①EFSの構築
- EFSのコンソールからファイルシステムの作成を押下
- カスタマイズを押下
- 名前を設定し、次へを押下
- 適切なネットワークおよびSGを設定し次へを押下
ファイルシステムポリシーはデフォルトのまま次へを押下
サマリを確認し、作成を押下
- 右上のアタッチを押下し、EFSをマウントするコマンドをコピーしておく
- 補足
NFSにアタッチするSGには、タイプ:NFSの通信を許可します。
②EC2へのEFSのマウント[1,2号機]
1号機の設定
- EFSをマウントするためにツールをインストール
yum install amazon-efs-utils
◆実行例
[root@fk-test-radius-01 ~]# yum install amazon-efs-utils Loaded plugins: extras_suggestions, langpacks, priorities, update-motd 215 packages excluded due to repository priority protections Resolving Dependencies --> Running transaction check ---> Package amazon-efs-utils.noarch 0:1.34.1-1.amzn2 will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================================================================================================================= Installing: amazon-efs-utils noarch 1.34.1-1.amzn2 amzn2-core 53 k Transaction Summary ============================================================================================================================================================================================================================================= Install 1 Package Total download size: 53 k Installed size: 205 k Is this ok [y/d/N]: y Downloading packages: amazon-efs-utils-1.34.1-1.amzn2.noarch.rpm | 53 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : amazon-efs-utils-1.34.1-1.amzn2.noarch 1/1 Verifying : amazon-efs-utils-1.34.1-1.amzn2.noarch 1/1 Installed: amazon-efs-utils.noarch 0:1.34.1-1.amzn2 Complete! [root@fk-test-radius-01 ~]#
- ①でコピーしたコマンドを利用し、EFSのマウント
◆実行例
[root@fk-test-radius-01 ~]# mount -t efs -o tls fs-0b07e9d6cb606fcc3:/ /mnt/home/ [root@fk-test-radius-01 ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 1969056 0 1969056 0% /dev tmpfs 1977848 0 1977848 0% /dev/shm tmpfs 1977848 572 1977276 1% /run tmpfs 1977848 0 1977848 0% /sys/fs/cgroup /dev/nvme0n1p1 8376300 1741400 6634900 21% / tmpfs 395572 0 395572 0% /run/user/0 tmpfs 395572 0 395572 0% /run/user/1000 127.0.0.1:/ 9007199254739968 0 9007199254739968 0% /mnt/home ★マウントされていることを確認 [root@fk-test-radius-01 ~]#
- /etc/fstabの設定
サーバ再起動時にEFSを自動でマウントできるように以下の設定を追加します。
file-system-id:/ efs-mount-point efs _netdev,noresvport,tls 0 0
◆設定例
[root@fk-test-radius-01 ~]# cat /etc/fstab # UUID=47834bf7-764e-42f9-9507-11a3e70b99de / xfs defaults,noatime 1 1 fs-0b07e9d6cb606fcc3:/ /mnt/home efs _netdev,noresvport,tls 0 0 [root@fk-test-radius-01 ~]#
◆確認
[root@fk-test-radius-01 ~]# umount /mnt/home/ [root@fk-test-radius-01 ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 1969056 0 1969056 0% /dev tmpfs 1977848 0 1977848 0% /dev/shm tmpfs 1977848 460 1977388 1% /run tmpfs 1977848 0 1977848 0% /sys/fs/cgroup /dev/nvme0n1p1 8376300 1740180 6636120 21% / tmpfs 395572 0 395572 0% /run/user/1000 [root@fk-test-radius-01 ~]# ## マウントポイントでマウントできるか確認 [root@fk-test-radius-01 ~]# mount /mnt/home/ [root@fk-test-radius-01 ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 1969056 0 1969056 0% /dev tmpfs 1977848 0 1977848 0% /dev/shm tmpfs 1977848 516 1977332 1% /run tmpfs 1977848 0 1977848 0% /sys/fs/cgroup /dev/nvme0n1p1 8376300 1740224 6636076 21% / tmpfs 395572 0 395572 0% /run/user/1000 127.0.0.1:/ 9007199254739968 0 9007199254739968 0% /mnt/home [root@fk-test-radius-01 ~]# ## 再起動後に自動マウントされるか確認 [root@fk-test-radius-01 ~]# shutdown -r now Connection to 52.199.191.70 closed by remote host. Connection to 52.199.191.70 closed. # [root@fk-test-radius-01 ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 1969060 0 1969060 0% /dev tmpfs 1977852 0 1977852 0% /dev/shm tmpfs 1977852 468 1977384 1% /run tmpfs 1977852 0 1977852 0% /sys/fs/cgroup /dev/nvme0n1p1 8376300 1740632 6635668 21% / 127.0.0.1:/ 9007199254739968 0 9007199254739968 0% /mnt/home tmpfs 395572 0 395572 0% /run/user/1000 [root@fk-test-radius-01 ~]#
2号機の設定
1号機の設定と同様の作業を実施します。
③Radiusサーバへユーザーの追加[1号機]
- Radiusサーバにユーザーを追加
useradd -u {空いているユーザーID} -g radius-enabled –c MFA –m –d /mnt/home/{ユーザー名} –s /sbin/nologin {ユーザー名}
◆実行例
[root@fk-test-radius-01 ~]# useradd -u 1003 -g radius-enabled -c MFA -m -d /mnt/home/fukushima -s /sbin/nologin fukushima [root@fk-test-radius-01 ~]# grep fukushima /etc/passwd fukushima:x:1003:1001:MFA:/mnt/home/fukushima:/sbin/nologin [root@fk-test-radius-01 ~]#
◆ポイント
- -dオプションによりホームディレクトリをEFS配下にすることでRadiusサーバ共通のホームディレクトリを用意しています。
- -mオプションによりホームディレクトリが存在する場合に再作成しないようにしています。Google Authenticatorの設定をした後に重要なファイルがホームディレクトリ配下に作成されるのですが、2号機側でユーザーを作成する際にホームディレクトリが再作成され、Google Authenticatorの設定ファイルが消えるのを避けるためです。
- -s /sbin/nologinによりユーザーのログインを禁止しています。MFAの認証にのみ利用するユーザーで作成したユーザーでRadiusサーバにログインすることはないためです。
④Google Authenticatorの設定
- Google Authenticatorの設定を行う
sudo -u {ユーザー名} /usr/bin/google-authenticator -tdf -r 3 -R 30 -S 30 -w 3
◆オプションの説明
- -t : 時間ベース(TOTP)の認証方式
- -d : TOTPトークンの再利用を禁止
- -f : コマンド実行時、ファイルの作成をユーザーに確認しない
- -r -R: ログインを 「-rで指定した秒」ごとに 「-Rで指定した回数」 に制限する
- -S : トークンの更新間隔を指定
- -w : 同時に有効なコードウィンドウの設定
◆実行例
sudo -u fukushima /usr/bin/google-authenticator -tdf -r 3 -R 30 -S 30 -w 3
QRコードが表示されるため、画像で実行例を記載いたします。
※コマンドの出力結果には重要なデータが表示されるため、取り扱いには注意してください。
- google_authenticatorの設定ファイル
設定が完了すると、ホームディレクトリ配下に.google_authenticatorという設定ファイルが生成されます。
[root@fk-test-radius-01 ~]# cat /mnt/home/fukushima/.google_authenticator 4LFKMC5K3BRU6DTBCXPOGULI5Y " RATE_LIMIT 3 30 " WINDOW_SIZE 3 " STEP_SIZE 30 " DISALLOW_REUSE " TOTP_AUTH 81993293 91658961 68173943 61423743 81058223 [root@fk-test-radius-01 ~]#
※上記内容は重要なデータのため、取り扱いには注意してください。
⑤Radiusサーバへユーザーの追加[2号機]
1号機と同様にユーザーを追加します。
useradd -u {空いているユーザーID} -g radius-enabled –c MFA –m –d /mnt/home/{ユーザー名} –s /sbin/nologin {ユーザー名}
◆実行例
[root@fk-test-radius-02 ~]# useradd -u 1003 -g radius-enabled -c MFA -m -d /mnt/home/fukushima -s /sbin/nologin fukushima useradd: warning: the home directory already exists. Not copying any file from skel directory into it. Creating mailbox file: File exists [root@fk-test-radius-02 ~]# grep fukushima /etc/passwd fukushima:x:1003:1001:MFA:/mnt/home/fukushima:/sbin/nologin [root@fk-test-radius-02 ~]# [root@fk-test-radius-02 ~]# ls -la /mnt/home/fukushima/.google_authenticator -r-------- 1 fukushima radius-enabled 150 Jan 17 08:35 /mnt/home/fukushima/.google_authenticator ★存在することがわかる [root@fk-test-radius-02 ~]#
2号機側では、既にEFSにホームディレクトリが存在するため、警告が出力されますが特に問題ありません。
⑥動作確認
2台が起動している場合と1台のみ起動している場合でWorkSpaceにログインできるか確認します。
- 2台起動時の結果
1号機を利用し、WorkSpaceにログインできたことを確認できました。
[root@fk-test-radius-01 ~]# grep radiusd /var/log/secure Jan 17 08:52:15 fk-test-radius-01 radiusd(pam_google_authenticator)[2232]: Accepted google_authenticator for fukushima [root@fk-test-radius-01 ~]#
- 1台起動時の結果(2号機のみ)
2号機を利用し、WorkSpaceにログインできたことを確認できました。
[root@fk-test-radius-02 ~]# grep radiusd /var/log/secure Jan 17 08:55:36 ip-10-88-1-132 radiusd(pam_google_authenticator)[2201]: Accepted google_authenticator for fukushima [root@fk-test-radius-02 ~]#
- 2台とも停止している場合の結果
当たり前ですが、ログインに失敗しました。
補足
EFSを用意せずにコマンドで対応したい場合
RADIUSサーバの冗長化のためには、.google_authenticatorが鍵となるため、 このファイルを1号機から2号機へ転送することでEFSなしでもRADIUSサーバを冗長化可能です。
以下は参考にやり方を記載いたします。
- 1号機でユーザーごとの.google_authenticatorをバックアップ
tar zcvf /tmp/mfa.tar.gz /home/*/.google_authenticator
◆実行例
[root@fk-test-radius-01 fukushima]# tar zcvf /tmp/mfa.tar.gz /home/*/.google_authenticator tar: Removing leading `/' from member names /home/fukushima/.google_authenticator /home/test01/.google_authenticator /home/test02/.google_authenticator /home/test03/.google_authenticator [root@fk-test-radius-01 fukushima]#
- ローカルから1号機に存在する.google_authenticatorのバックアップをダウンロード
scp -i fk-test-key.pem ec2-user@[1号機のIP]:/tmp/mfa.tar.gz ./
◆実行例
# scp -i fk-test-key.pem ec2-user@[1号機のIP]:/tmp/mfa.tar.gz ./ mfa.tar.gz 100% 1727 69.5KB/s 00:00 #
- ローカルから2号機へ.google_authenticatorのバックアップをアップロード
scp -i fk-test-key.pem mfa.tar.gz ec2-user@[2号機のIP]:/tmp/
◆実行例
# scp -i fk-test-key.pem mfa.tar.gz ec2-user@[2号機のIP]:/tmp/ mfa.tar.gz 100% 1727 167.7KB/s 00:00 #
- 2号機でtarの展開
cd /tmp tar zxvf mfa.tar.gz
◆実行例
[root@fk-test-radius-02 /]# cd /tmp [root@fk-test-radius-02 tmp]# tar zxvf mfa.tar.gz home/fukushima/.google_authenticator home/test01/.google_authenticator home/test02/.google_authenticator home/test03/.google_authenticator [root@fk-test-radius-02 tmp]#
- tarのデータを各ユーザーのホームディレクトリに格納
cd /home for user_name in $(ls) do cp -p ${user_name}/.google_authenticator /home/${user_name}/ ls -la /home/${user_name}/.google_authenticator done
◆実行例
[root@fk-test-radius-02 /]# cd /home [root@fk-test-radius-02 home]# for user_name in $(ls) > do > cp -p ${user_name}/.google_authenticator /home/${user_name}/ > ls -la /home/${user_name}/.google_authenticator > done -r-------- 1 fukushima radius-enabled 150 Jan 17 10:29 /home/fukushima/.google_authenticator -r-------- 1 test01 radius-enabled150 Jan 17 10:11 /home/test01/.google_authenticator -r-------- 1 test02 radius-enabled150 Jan 17 10:11 /home/test02/.google_authenticator -r-------- 1 test03 radius-enabled150 Jan 17 10:11 /home/test03/.google_authenticator [root@fk-test-radius-02 home]#
終わりに
今回は、WorkSpaces環境におけるRadiusサーバの冗長化をEFSを利用して実装する構成について、ご紹介いたしました。
EFSなしでも冗長化可能なものの運用負荷を軽減するためには、EFSの導入するのはありだなと感じました。
どなかたのお役に立てれば幸いです。