LoginSignup
10
10

More than 3 years have passed since last update.

@Kobecow

SSMのSession Manager触ってみた

Last updated at Posted at 2018-11-20

概要

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系
ネットワーク: インターネットアクセスあり

以下はただの作業ログ

[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

画面右上のAction > Start Session を選択
2018-11-19 (2)_LI.jpg

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

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

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

2018-11-19 (8).png

準備はできた

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

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

2018-11-19 (13).png

追加された。

2018-11-19 (15).png

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

SSのログをS3にアウトプットさせてみる

AWS管理コンソールからSSM > Session Manager > Preferences > Edit　を選択し、出力するS3Bucketを選択します。
2018-11-20.png

準備は以上です。あとはSSを使用するだけです。
Session Manager > Session history　を選択すると、過去のSSの使用履歴が表示されます。
2018-11-20 (1).png

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

ログ
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[Ksudo 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[Kecho ""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 ~]# exitchmod 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

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

スクリーンショット 2018-11-20 23.53.13.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

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

スクリーンショット 2018-11-21 0.33.02.png

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

成功した方法

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

JSONの一部分、編集前

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

"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

スクリーンショット 2018-11-21 0.53.51.png

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

10
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
10
10