mediba advent calendar 2017 15日目担当の沼沢 @numasawa です。
インフラストラクチャー部所属、AWS インフラ全般やってます。
SSM の記事ではありますが、タイトルに深い意味はありません。

皆さん、SSM 使ってますか？というより知っていますか？
Amazon EC2 Systems Manager ←こいつですね。

今回はこの SSM についてお話をしたいと思います。

なお、"SSM" は Simple Systems Manager の略なのですが、公式紹介ページでの名称から Simple が無くなっているのはとても深い謎です。
公式ドキュメント内でも表記が揺れているようですので、気にしないでおきましょう。

SSM とは

そもそも SSM とはなんぞや。
一番簡単な使い所で言うと、ssh ログインせずとも、Management Console 上から Agent 経由で OS 上でコマンドを実行してくれるサービスです。

これの何が嬉しいかというと、ssh ログインが必要無くなります。
→ 踏み台などの ssh ログインの口を用意する必要がない
→ 侵入経路を無くすことができる
　　＿人人人人人人人人人＿
→　＞　 テラセキュア 　＜
　　￣Y^Y^Y^Y^Y^Y^Y^Y￣

ということで、SSM を積極的に使っていきたい、そして ssh レスなシステムを作り上げたいという壮大な夢が広がりんぐなわけです。

SSM を試す

※試すだけなので、諸々権限ゆるゆるです。実際に利用する場合は要件に沿って適宜制限しましょう。

まずは以下のものを用意します。

準備

AmazonEC2FullAccess, AmazonSSMFullAccess が付いた IAM ユーザ
AmazonSSMFullAccess が付いた EC2 用 IAM ロール
インターネットアクセスが可能な状態の EC2 インスタンス
- Amazon Linux AMI 2017.09 の AMI を選択
- 1. の IAM ロールを付与する
- アウトバウンドができれば OK、インバウンドは何も開けなくて良い

上記で EC2 インスタンスが起動すると、EC2 コンソールのサイドメニュー「マネージドインスタンス」の一覧に、起動した EC2 インスタンスが表示されるので、これで準備完了です。

実行

では、ls -la を実行してみましょう。
サイドメニューから「コマンドの実行」表示→「コマンドの実行」ボタンを押下し、以下の手順で実行してみます。

注意点

とても便利な SSM ですが、Run Command では root 権限でコマンドが発行されます。
つまり、オペミスで停止する予定ではなかったプロセスを停止してしまったり、悪意を持った IAM ユーザが rm -rf / などを発行することが可能、ということです。
怖いですねー。
以下のようにバルスを唱えることだってできてしまいます。

ドキュメントを用意してオペミス等を極力減らす

例えば、httpd プロセスを再起動したいと思った時に、上記と同じ手順で service httpd start を実行してプロセスを起動！としようとした時に、手動では "httpd" の部分を間違える可能性がどうしてもありますよね。

とにかくオペミスが怖い！ので、決まったコマンドを発行するだけなら、ドキュメント化すると少し安心できます。

Systems Manager ドキュメント

例に上げた、httpd プロセスの再起動をするためのドキュメントはこんな感じになります。(バージョン2.2で作成)

{
  "schemaVersion": "2.2",
  "description": "ApacheRestart",
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "apacheRestart",
      "precondition": {
        "StringEquals": [
          "platformType",
          "Linux"
        ]
      },
      "inputs": {
        "runCommand": [
          "service httpd restart"    ←ここに実行したいコマンドを書く
        ]
      }
    }
  ]
}

なお、runCommand の配列にコマンドを列挙すれば、定義した順に実行できます。
これをサイドメニュー「ドキュメント」→「ドキュメントの作成」から新規に登録します。

ではこれを実行してみたいと思います。

出力結果を確認します。

ここまでできると、IAM ポリシーでこのドキュメントだけを許可するといった制御が可能になるので、Apache の再起動のみしかできないためオペミスも無くなりますし、悪意を持った IAM ユーザでも Apache の再起動しかできない、ということになりますので、かなりセキュアになるかと思います。

IAM ポリシーはこの辺が参考になるかと。
Systems Manager のアクセス設定

その他

SSM Agent は Amazon Linux AMI 2017.09 からはデフォルトでインストール済みで、この AMI でインスタンスを起動すると Agent もデフォルトで起動するようになっています。
https://aws.amazon.com/jp/blogs/news/now-available-amazon-linux-ami-2017-09/

あとがき

いつかの AWS re:Invent で、現地のエンジニアから、「えーマジまだ ssh してるの！？ssh が許されるのは(ry」(※)的なこと言われて衝撃だったのを今でも覚えてます。
※実際には「なぜ ssh する必要があるんだい？」ぐらいの感じでした。

ssh レスなシステムを作り上げてみたい、そのうち。

追記 (2018年10月)

先日、セッションマネージャーなる機能が登場しました。
この機能を使うと、SSH レスという夢に近付く気がしています。ご参考まで。