SSMのSessionManager
以前、少しだけSessionManagerを触る機会があり
その時に感じていた疑問を少し整理しつつ
じゃあ何ができるんだろうと言うところをまとめようと思います。
環境の整理
ここに記載のあるとおり、環境を整理します。
ポイントは大きく以下です
- amazon-ssmのagentが対象のEC2にInstallされている
- 対象のEC2にIAM Policy「AmazonEC2RoleforSSM」を含むEC2インスタンスRoleが付与されている
今回は最初からamazon-ssmのagentがInstallされているAmazonLinux2の以下AMIを
使用して確認しました。
amzn2-ami-hvm-2.0.20190508-x86_64-gp2 (ami-00d101850e971728d)
また余談ですが、対象のインスタンス起動後にEC2のロールを付与した場合、
amazon-ssm-agentのサービス起動時に権限不足が生じ、かつ
それを動的（つまりロールの後付け）で解消できないらしくサービスの再起動が必要でした。
確認
AWS ManagementConsoleからWebUIで操作します。
なかなかの気持ち悪さ
ssm-userのお前誰やねん感と何で表示されないねん感はなかなかです。
sh-4.2$ whoami
ssm-user
sh-4.2$
# 確認のため裏でSSH経由のログインをしています
sh-4.2$ w
10:59:11 up 2:11, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ec2-user pts/0 xxx 08:47 8:14 0.09s 0.00s sshd: ec2-user [priv]
sh-4.2$
sh-4.2$
なかなかの気持ち悪さ その２
以下はSessionManager開始直後に叩いた結果ですが
もはや何を信じていいかわからない感がしびれますね
sh-4.2$ cat /etc/passwd | grep ssm
ssm-user:x:1001:1001::/home/ssm-user:/bin/bash
sh-4.2$
sh-4.2$ pwd
/usr/bin
sh-4.2$
sh-4.2$ echo $0
sh
sh-4.2$ echo $SHELL
/bin/bash
sh-4.2$
SSH?そんなものいらねえ感
どころか、もはや他のそれらしいサービスが待ち受けてすらない感。
第一オクテット52がSSMの通信のそれだろうけど、外に出ていく方ですね。
[root@ip-172-16-0-88 ~]# systemctl stop sshd
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2673/rpcbind
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3147/master
tcp 0 0 172.16.0.88:33760 52.119.218.91:443 ESTABLISHED 3973/amazon-ssm-age
tcp 0 0 172.16.0.88:47362 54.240.225.173:443 ESTABLISHED 3973/amazon-ssm-age
tcp 0 471 172.16.0.88:33798 52.119.218.91:443 ESTABLISHED 3984/ssm-session-wo
tcp6 0 0 :::111 :::* LISTEN 2673/rpcbind
udp 0 0 0.0.0.0:712 0.0.0.0:* 2673/rpcbind
udp 0 0 127.0.0.1:323 0.0.0.0:* 2676/chronyd
udp 0 0 0.0.0.0:68 0.0.0.0:* 2882/dhclient
udp 0 0 0.0.0.0:111 0.0.0.0:* 2673/rpcbind
udp6 0 0 :::712 :::* 2673/rpcbind
udp6 0 0 fe80::46a:73ff:fe36:546 :::* 3013/dhclient
udp6 0 0 ::1:323 :::* 2676/chronyd
udp6 0 0 :::111 :::* 2673/rpcbind
# snip
何でもできる潔さ
めちゃんこ強いです
sh-4.2$ sudo su -
Last login: Sat Jun 8 08:47:46 UTC 2019 on pts/0
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# grep -r ssm /etc/sudoers*
/etc/sudoers.d/ssm-agent-users:# User rules for ssm-user
/etc/sudoers.d/ssm-agent-users:ssm-user ALL=(ALL) NOPASSWD:ALL
[root@ip-172-16-0-88 ~]#
何度でも蘇る
セッションマネージャーでの接続を一旦切り
SSHでログインしているターミナルでssm-userを消しても
amazon-ssm-agentサービスの再起動で蘇ります。
※何をやっているかは/var/log/secureを見ていただけるとわかりやすいです。
[root@ip-172-16-0-88 ~]# cat /etc/passwd | grep ssm-user
ssm-user:x:1001:1001::/home/ssm-user:/bin/bash
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# userdel -r ssm-user
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# systemctl restart amazon-ssm-agent.service
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# cat /etc/passwd | grep ssm-user
ssm-user:x:1001:1001::/home/ssm-user:/bin/bash
[root@ip-172-16-0-88 ~]#
無論強さもそのままです
何度でも強い時のあの自分のまま復活します。
[root@ip-172-16-0-88 ~]# ll /etc/sudoers.d/ssm-agent-users
-r--r----- 1 root root 58 Jun 8 11:13 /etc/sudoers.d/ssm-agent-users
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# rm -f /etc/sudoers.d/ssm-agent-users && date
Sat Jun 8 11:14:16 UTC 2019
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# systemctl restart amazon-ssm-agent.service && date
Sat Jun 8 11:14:33 UTC 2019
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# ll /etc/sudoers.d/ssm-agent-users
-r--r----- 1 root root 58 Jun 8 11:14 /etc/sudoers.d/ssm-agent-users
[root@ip-172-16-0-88 ~]#
封じ込めるか
SSH側のセッションで以下実行
やってやりましたよ。
[root@ip-172-16-0-88 ~]# visudo -f /etc/sudoers.d/ssm-agent-users
[root@ip-172-16-0-88 ~]# cat /etc/sudoers.d/ssm-agent-users
# User rules for ssm-user
ssm-user ALL=(ALL) NOPASSWD:/usr/bin/su - ec2-user
[root@ip-172-16-0-88 ~]#
[root@ip-172-16-0-88 ~]# systemctl restart amazon-ssm-agent.service
[root@ip-172-16-0-88 ~]# cat /etc/sudoers.d/ssm-agent-users
# User rules for ssm-user
ssm-user ALL=(ALL) NOPASSWD:/usr/bin/su - ec2-user
[root@ip-172-16-0-88 ~]#
まとめ
踏み台サーバを不要化できるかなとか、そういう考えも少しあり、
でも何でもできる匿名ユーザだと
誰が触ったの？とか（IAM User/CloudTrail側で何とかしようと言う向きもあると言うかそれが正しいのかもしれませんが）心配な面もありましたが、sudo周りの制限である程度制御できそうな気もします。
※各サーバに個々人のユーザ追加が必要になるので、LDAPか何かが欲しいですが。
なかなかの気持ち悪さのところは少し調べましたがすぐすぐ回答が出せませんでした。
わかる方いらっしゃったら是非ご教示ください。
![[AWS]CloudFormationテンプレート作成 その１](https://www.simpline.co.jp/wp-content/themes/sankakuya_skelton/img/noimage.png)