SSMのSession Manager触ってみた

# 概要
2018年11月現在、比較的新しいサービスであるSystems Manager(以下SSM)のSession Manager(以下SS)の機能を色々試してみた

# SSについて
ざっくりいうとEC2に**sshしない**でコマンドを叩ける機能
SSMの機能の一つにSSがある


#普通に導入して使ってみる
導入方法はこちらを参照した。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-manual-agent-install.html

前提として
OS: CentOS7系
ネットワーク: インターネットアクセスあり

以下はただの作業ログ

```text:
[centos@ip-10-0-0-233 ~]$ mkdir /tmp/ssm
[centos@ip-10-0-0-233 ~]$ cd /tmp/ssm
[centos@ip-10-0-0-233 ssm]$ sudo yum install -y https://s3.amazonaws.com/ec2-dow                       nloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
Loaded plugins: fastestmirror
amazon-ssm-agent.rpm                                     |  19 MB     00:02
Examining /var/tmp/yum-root-VERKmz/amazon-ssm-agent.rpm: amazon-ssm-agent-2.3.27                       4.0-1.x86_64
Marking /var/tmp/yum-root-VERKmz/amazon-ssm-agent.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package amazon-ssm-agent.x86_64 0:2.3.274.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package              Arch       Version            Repository             Size
================================================================================
Installing:
 amazon-ssm-agent     x86_64     2.3.274.0-1        /amazon-ssm-agent      61 M

Transaction Summary
================================================================================
Install  1 Package

Total size: 61 M
Installed size: 61 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : amazon-ssm-agent-2.3.274.0-1.x86_64                          1/1
Created symlink from /etc/systemd/system/multi-user.target.wants/amazon-ssm-agen                       t.service to /etc/systemd/system/amazon-ssm-agent.service.
  Verifying  : amazon-ssm-agent-2.3.274.0-1.x86_64                          1/1

Installed:
  amazon-ssm-agent.x86_64 0:2.3.274.0-1

Complete!
[centos@ip-10-0-0-233 ssm]$ sudo systemctl status amazon-ssm-agent
● amazon-ssm-agent.service - amazon-ssm-agent
   Loaded: loaded (/etc/systemd/system/amazon-ssm-agent.service; enabled; vendor                        preset: disabled)
   Active: active (running) since Mon 2018-11-19 01:45:48 UTC; 13s ago
 Main PID: 23182 (amazon-ssm-agen)
   CGroup: /system.slice/amazon-ssm-agent.service
           mq23182 /usr/bin/amazon-ssm-agent

Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal systemd[1]: Sta...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal systemd[1]: Sta...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Nov 19 01:45:48 ip-10-0-0-233.ap-northeast-1.compute.internal amazon-ssm-agent[2                       3182]: ...
Hint: Some lines were ellipsized, use -l to show in full.
[centos@ip-10-0-0-233 ssm]$
```

EC2にアタッチするIAMロールについては以下のポリシーが必要
**AmazonEC2RoleforSSM**(必須)
AmazonS3FullAccess（SSを使用した時のログをs3に出力したい場合に必要）

###それではAWSの管理コンソールよりSSを試してみる
SSMのManaged instacesの画面
![2018-11-19_LI (2).jpg](https://qiita-image-store.s3.amazonaws.com/0/158076/02df1b10-4cc3-5750-5e83-db623e38e350.jpeg)

画面右上のAction > Start Session を選択
![2018-11-19 (2)_LI.jpg](https://qiita-image-store.s3.amazonaws.com/0/158076/b68b741e-ba42-4115-9e4d-c70edd7bc2ac.jpeg)


SSが使用できました。

#インターネットアクセスがない環境で使ってみる

次にインターネットアクセスできない環境でSSを使用してみます。
参考にしたサイト（https://dev.classmethod.jp/cloud/aws/ec2-elb-kinesis-service-catalogsystems-manager-vpc-endpoint-support/）

まずはEC2をプライベートサブネット内に作成し、PublicDNS名、Elastic IPはつけずインターネットにアクセスできない状態にする。
IAMロールは先ほど使用したものと同じのをアタッチします。
![2018-11-19 (7).png](https://qiita-image-store.s3.amazonaws.com/0/158076/36a45e98-6117-6ba3-9e6d-e9a3fac6f3c3.png)

ssmAgentをrpmから導入していきます。

```text:terminal
[root@ip-10-2-0-61 tmp]# yum install amazon-ssm-agent.rpm
Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
Examining amazon-ssm-agent.rpm: amazon-ssm-agent-2.3.274.0-1.x86_64
Marking amazon-ssm-agent.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package amazon-ssm-agent.x86_64 0:2.3.274.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                    Arch             Version                 Repository                   Size
=======================================================================================================
Installing:
 amazon-ssm-agent           x86_64           2.3.274.0-1             /amazon-ssm-agent            61 M

Transaction Summary
=======================================================================================================
Install  1 Package

Total size: 61 M
Installed size: 61 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : amazon-ssm-agent-2.3.274.0-1.x86_64                                                 1/1
Created symlink from /etc/systemd/system/multi-user.target.wants/amazon-ssm-agent.service to /etc/systemd/system/amazon-ssm-agent.service.
  Verifying  : amazon-ssm-agent-2.3.274.0-1.x86_64                                                 1/1

Installed:
  amazon-ssm-agent.x86_64 0:2.3.274.0-1

Complete!
```

これでインターネットアクセスできる環境だとSSが使用できましたが、今回はインターネットアクセスが無いのでエンドポイントを作成する必要があります。

### VPCエンドポイントを作成
AWS管理コンソールから VPC > Endpoints > Create Endpointsを選択
以下のエンドポイントを一つ一つ作成していきましょう。

com.amazonaws.ap-northeast-1.ssm
com.amazonaws.ap-northeast-1.ec2
com.amazonaws.ap-northeast-1.ssmmessages


- 先ほど作成したEC2が属するVPCを選択
- サブネットはENI(Elastic Network Interface)が作成されるサブネットなので、EC2と通信できればどこでもよい。(よく分からない人はEC2と同じサブネットにしましょう)
- Enable Private DNS Nameはチェックを入れましょう。
- Security GroupはVPC内からの全てのIPから80,443を許可するもの選択しました。(最低限、EC2から443を許可すればいいはず)
![2018-11-19 (4).png](https://qiita-image-store.s3.amazonaws.com/0/158076/a053950a-52e0-d632-640a-b73d329969a3.png)


![2018-11-19 (8).png](https://qiita-image-store.s3.amazonaws.com/0/158076/9222341b-8186-f7d7-d3dc-691c611982bf.png)

###準備はできた
しかし、SSMのManaged instancesにエントリーは追加されていなかった。(つらたん)
SSMAgentを再起動した。

```text:terminal
[root@ip-10-2-0-61 ~]# systemctl restart amazon-ssm-agent
```

![2018-11-19 (13).png](https://qiita-image-store.s3.amazonaws.com/0/158076/e63e6773-aa3d-31c7-0619-d7405ba94c56.png)

追加された。

![2018-11-19 (15).png](https://qiita-image-store.s3.amazonaws.com/0/158076/b64eca58-74bf-dac5-3255-3bb141cdae44.png)

インターネットアクセスできなくてもSSが使用できましたね。
次はログ周りを見ていきましょう。
**追記**
エンドポイントは維持費が結構かかります。3つ維持すると50US$ほどかかります。検証が済んだら必ず削除しましょう。

#SSのログをS3にアウトプットさせてみる
AWS管理コンソールからSSM > Session Manager > Preferences > Edit　を選択し、出力するS3Bucketを選択します。
![2018-11-20.png](https://qiita-image-store.s3.amazonaws.com/0/158076/4824f4bd-6f50-0810-fafa-17d131f528b2.png)

準備は以上です。あとはSSを使用するだけです。
Session Manager > Session history　を選択すると、過去のSSの使用履歴が表示されます。
![2018-11-20 (1).png](https://qiita-image-store.s3.amazonaws.com/0/158076/cc72ee25-a5d8-cca6-cc8e-4457ac3dd080.png)

Output locationにログの出力先へのリンクがあります。
私がSSを使用した時のログが以下です。

```text:ログ
Script started on Mon 19 Nov 2018 02:13:49 PM UTC
[?1034hsh-4.2# /usr/bin/ssm-session-logger /var/lib/amazon/ssm/i-012785dd80db60194/sess 
ion/orchestration/root-0cdc362ce3b239470/Standard_Stream/ipcTempFile.log false
Error occurred fetching the seelog config file path:  open /etc/amazon/ssm/seelog.xml: no such file or directory
Initializing new seelog logger
New Seelog Logger Creation Complete
[?1034hsh-4.2$ 
[Ksh-4.2$ 

sh-4.2$ 

sh-4.2$ echo ""I"s" "t"h"i" "[1P"s" "r"e"d"[1P"c"o"r"r"[1P"[1P"r"e"[1P"d"e"d"[1P"[1P"[1P"[1P"[1P"[1P"[1P"[1P"[1P"[1P"[1P"[1P"h"i"s" "l"o"g"g"e"d" "b"y" "[1P"[1P"[1P"i"n"[1P"[1P"b"y" "s"s" "[1P"[1P"[1P"S"S"?"

Is this logged by SS?

sh-4.2$ sy[K[Ksudo su -

Last login: Mon Nov 19 02:06:50 UTC 2018 on pts/0

]0;root@ip-10-0-0-233:~[?1034h[root@ip-10-0-0-233 ~]# su -[K[K[K[Kecho ""H"e"l"l"o"w" "[1P"[1P"[1P"[1P"[1P"[1P"[1P"h"e"l"l"o"[1P"[1P"[1P"[1P"[1P"H"w"l"l"o" "[1P"[1P"[1P"[1P"[1P"e"l"l"o" "W"o"r"l"d"!"!"[1P"

-bash: !": event not found

[root@ip-10-0-0-233 ~]# echo ""H"e"!"

-bash: !": event not found

[root@ip-10-0-0-233 ~]# exitchmod 777 amazon-ssm-agent.rpm 
[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[Cexit[K[Kexit

logout

sh-4.2$ exit

exit

sh-4.2# exit
exit

Script done on Mon 19 Nov 2018 02:14:54 PM UTC

```

ちょっと使い物にならないですね。
ただ、このメモをMacのCLIで`cat`すると一切文字化けせずにみることができました。


#EC2ごとにSSのアクセス制御を実現

結論から申し上げると、AWSのサポート外のことをしないとできなかったです。
色々なやり方があると思うので、私のやり方が筋が悪いだけかもしれませんが。

では、その筋悪を紹介します。
まず、EC2を二つ用意します。EC2-01,EC2-02とします。
`Name `というTagを使用して、アクセス制御を実現していきます。

| EC2              | Key               | Value             |
|:-----------------|:------------------|:------------------|
| EC2-01           | Name              | CentOS7-01        |
| EC2-02           | Name              | RHEL7-01          |

IAMユーザーもアクセス制御している感を出すため二つ用意します。

| IAMユーザー        | Policy               |              
|:-----------------|:------------------|
| test01           | AmazonSSMFullAccess              |         
| test02           | test-policy01              |        

当たり前ですが、test01は両方のEC2にSSでアクセスできます。
test02にアタッチしたポリシー(`test-policy01`)はAmazonSSMFullAccessをベースとしたカスタムポリシーです。


###test-policy01の作成手順
AWS管理コンソールよりIAM > Policies > Create Policy
![スクリーンショット 2018-11-20 23.50.41.png](https://qiita-image-store.s3.amazonaws.com/0/158076/91fe003c-813c-c887-3ae3-36f294a742d0.png)

画面右上の`Import managed policies `をクリック
`AmazonSSMFullAccess` を選択し、Importをクリック
おそらく以下のような画面になるかと

![スクリーンショット 2018-11-20 23.53.13.png](https://qiita-image-store.s3.amazonaws.com/0/158076/aac1d05b-90f8-a0c7-e253-7cc18b057010.png)
`EC2`,`EC2 Messages`, `CloudWatch Logs`等々が表示されます。この内容はAmazonSSMFullAccessポリシーと同じ内容です。

###駄目な方法①
上図のポリシー編集画面のSystems Mangerの行を展開して、Resources > Sesssionの部分にEC2のARNとかEC2のインスタンスIDを指定すればイケるんじゃね。って思いましたが。駄目でした。その当時の私は何もわかっていなかった。ただ夕日が赤いなぁって。
 =>駄目な理由はSessionのリソースに指定できるのは~~Session IDです。**EC2のリソースを指定することはできません。**~~
インスタンスIDを指定し、SSのアクセス制御ができます。後日追記予定

###駄目な方法②
では、EC2-02に`Test-01`というTagをつけます。Valueは何も設定しません。
![スクリーンショット 2018-11-21 0.15.27.png](https://qiita-image-store.s3.amazonaws.com/0/158076/4822764c-666d-632c-e3ff-fedc6d21b3d8.png)


またポリシー編集画面に戻って、Systems Mangerの行を展開してActionsを編集します。
`All Systems Manager actions (ssm:*) `のチェックを外し、Sessionに関係しそうなStartSession,ResumeSession,TerminateSessionからチェックを外します。
こんなかんじです。
![スクリーンショット 2018-11-21 0.21.43.png](https://qiita-image-store.s3.amazonaws.com/0/158076/8aa870d9-28ed-4d13-2aba-df98caabc5d0.png)
次にSystems Managerの行の`Clone`をクリックします。
そしてクローンされたSystems Managerを展開し、Actionsはさきほどの3つ(StartSession,ResumeSession,TerminateSession)のみにチェックを入れます。
ResoucesはSessionしか選べないので、もちろんAnyです。
Request ConditionsでTag名を指定しれやればうまく行くんじゃね。ほら、こんなかんじで。

![スクリーンショット 2018-11-21 0.33.02.png](https://qiita-image-store.s3.amazonaws.com/0/158076/12b8cde1-7c32-6d8f-2e8c-a7f606122bb2.png)

`Test01`というTagを持ったEC2のみにSSでアクセスできると思っていました。両方のEC2にSSでアクセスできなかった。その当時の私はまだまだ経験が足りず、なんでも自分の力でできると思っていた。ただみんなが帰った後の部屋でAWSのドキュメントを読んでいた。
=>駄目な理由はここで指定しているTest01は**リクエスト出す側(IAMユーザー)**のTagを指している。リクエストされる側のEC2は関係ない。そもそもリクエストされるのはEC2ではなく、SSだ。

###成功した方法
駄目な方法②で作成したポリシーを再利用します。ポリシー編集画面からついに`JSON`を直に編集していきます。
以下の場所をごっそり変換します。

```ruby:JSONの一部分、編集前

"Effect": "Allow",
            "Action": [
                "ssm:ResumeSession",
                "ssm:TerminateSession",
                "ssm:StartSession"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:TagKeys": "Test01"
                }
            }

```

```ruby:編集後

"Effect": "Allow",
            "Action": [
                "ssm:ResumeSession",
                "ssm:TerminateSession",
                "ssm:StartSession"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "ssm:resourceTag/Name": "RHEL7-01"
                }
            }

```

これだけです。編集後はReview policyをクリックします。
これでtest02はEC2に`RHEL7-01`というTagがついたEC2のみにSSでアクセスすることができました。
やったね。

###警告内容
しかし、IAMポリシーの編集画面には`There are no actions in your policy that support this condition key.`という警告が出ている。今回のcondtionの指定方法はサポートされていないとのこと。

![スクリーンショット 2018-11-21 0.53.39.png](https://qiita-image-store.s3.amazonaws.com/0/158076/fd63559d-3a3e-8201-4a47-e2845f8ae7a7.png)

![スクリーンショット 2018-11-21 0.53.51.png](https://qiita-image-store.s3.amazonaws.com/0/158076/1aae80a9-c63d-f4b9-2d78-827588148e75.png)

AWSサポートに問い合わせた結果、今回のIAMポリシーの書き方はサポートされているので特に気にする必要ないとのこと。