2020年10月7日 / 最終更新日時 : 2020年10月28日 Nissy AWS

AWS Systems Manager の開始設定

Amazon Linux2 においてのAWS Systems Manager開始手順です。2020年のAWS Systems ManagerのBlackbeltを見ながら、手を動かしながら記事作りました。この記事ではSSMのログ（CloudWatch / S3）や暗号化(KMS encryption)などには触れていません。

Amazon Linux2へSSM Agentのインストール

こんな風に記事を書いてますが、Amazon Linux 2 には、実は、デフォルトでSSＭ Agentがインストールされています。それで、インストール作業不要と思われますが、きちんとインストールされていない場合もありハマります。念のため、SSM Agentの存在確認を以下のステータス確認コマンドでしましょう。SSM Agentを設定後に自動でSSM AgentのバージョンがアップデートされるのでSSM Agentのバージョンを覚えておくといいです。

//ステータス確認コマンド
sudo systemctl status amazon-ssm-agent

経路確保

以下2つの場合に別けて経路確保します。NatGatewayのお値段がそれなりにお高かった記憶あり。

パブリックサブネットなどインターネット経由の場合

  • インバウンドアクセス不要
  • パブリックサブネット か Nat Gateway を使う

プライベートサブネットなどVPCエンドポイント経由の場合

  • プライベートネットワーク可能（Nat Gatewayを利用する）

「VPCエンドポイント」をサブネット単位かつ東京リージョンならAZの1a/1c/1dの別々で、サービスカテゴリは「AWSサービス」で、以下の3種「サービス名」にて作る必要があります。

  1. com.amazonaws.ap-northeast-1.ssm
  2. com.amazonaws.ap-northeast-1.ssmmessages
  3. com.amazonaws.ap-northeast-1.ec2messages
  4. com.amazonaws.region.s3

上記３種のVPCエンドポイントのセキュリティグループについて、インバウンドで HTTPS 443、ソースは、SSMセッションマネージャーをしたいEC2があるVPCのプライベートサブネットの「サブネットCIDR」（もしくは「VPCのCIDR」）を指定します。

エンドポイント作成中は、多少の待ち時間が必要です。

プライベートサブネットでVPNエンドポイントを作らない場合、SSMセッションマネージャーが使えず、「AWS ClientVPN」や「サイト間のVPN接続」の実行中でないとプライベートサブネットのEC2インスタンスにSSH接続出来ないです。

IAMロール設定

IAMポリシーの　AmazonSSMManagedInstanceCore　をEC2インスタンスのIAMロールに設定します。過去、AmazonEC2RoleforSSMでしたが、デフォルトで許可する権限が広いため、今は、AmazonSSMManagedInstanceCore　が推奨されています。

OpsCenterの有効化

有効化をクリック

リソースのグルーピング

AWS Resource Groups　にてリソースをグルーピングします。※必須では無いです

高速セットアップ（Quick Setup）

そのまま実行します。EC2インスタンス全部、1台だけなど、指定できます。

※CloudWatchのAgent設定ファイル（デフォルトは、/opt/aws/amazon-cloudwatch-agent/bin/config.json）が、EC2インスタンス内に既に存在している状態で高速セットアップを実行しても設定ファイルはリセットされず、高速セットアップ以前の値は保持されました。

セッションマネージャーを起動してみる

  1. AWS Systems Managerへ（リージョンに気を付けてください）
  2. セッションマネージャー（左サイドバー）へ
  3. 「セッションの開始」をクリック
  4. インスタンス一覧から1台を選択する
  5. 「セッションを開始する」をクリック

セッションマネージャーは、SSHログインではなく、シェルアクセスとのことです。

SSHのキーペアを削除したいところですが、シェルアクセスとSSHログインの違いがよくわかりません。

ただ、AmazonLinux2内にあるSSH接続キーをあえて削除して、SSMセッションマネージャも使えなくなった場合、SSH接続再開方法は次のとおり。

  1. 接続不能状態のEC2インスタンスを停止
  2. EBSボリュームのデタッチ
  3. 新しいキーペアで改めてEC2を起動
  4. デタッチしたEBSボリュームを新しいキーペアで改めて作ったEC2インスタンスに接続
  5. 新しいEC2にSSH接続して、EBSボリュームをマウント、/.ssh/authorised_keysをマウントしたEBSボリュームにコピーで貼り付け
  6. 新しいEC2を停止、そこからマウントしたEBSボリュームをデタッチ
  7. 最初の接続不能状態のEC2インスタンスにEBSボリュームをアタッチ、新しいキーペアでSSH接続出来る事を確認してください。

EBSボリュームのデタッチ

Linux インスタンスからの Amazon EBS ボリュームのデタッチ

AmazonLinux2のec2-userへのLinuxユーザー切替

SSMのセッションマネージャーが使えることになると、踏み台サーバやSSH接続を除去することもあると思います。くれぐれもAWSのルートユーザーとIAMユーザーの方々は多要素認証してください。

rootユーザーへの切替は定番のコマンド

sudo su -

ec2-userユーザーへの切替コマンド（rootになってから使うとパスワード不要）

su ec2-user

SSMのマネージドインスタンスで「Pingの状態」が「オンライン」にならない

AWS Systems Mangerのマネージドインスタンス画面でManeged Instanceとして認識されなず、「接続が失われました」となってしまうEC2インスタンスがあります。Maneged Instanceにするにはどうしたらいいんだろ。

セッションマネージャーで「セッションを開始する」クリック後、

「インスタンスにある SSM エージェントのバージョンが Session Manager をサポートしていませんが、インスタンスも AWS Systems Manager との使用向けに設定されていません。インスタンスにアタッチされている IAM インスタンスプロファイルに必要な許可が含まれていることを確認してください。詳細情報はこちらをご覧ください」

と表示されます。

起動中Amazon Linux2のEC2インスタンスから作られたAMIイメージのEC2インスタンスは関係あるだろうか？

「EBSスナップショット」

もしくは

「起動中Amazon Linux2のEC2インスタンスから作られたAMIイメージ」

から作られたEC2インスタンスのAWS Systems Mangerとの相性については、出来ていませんが詳しく調べたほうがいいかも。

とりあえず、AmazonLinux2のSSMエージェント再起動してみる

sudo systemctl amazon-ssm-agent restart

パブリックサブネットのEC2インスタンスでセッションマネージャーのプロンプトが表示されない

CloudWatchLogsのセッションマネージャーのログ設定について、以下の確認をしてください。セッションマネージャーログ保存場所は、S3とCloudWatchLogsの2箇所あります。

EC2インスタンスのセッションマネージャーのログ向けにS3バケットを作り、EC2インスタンスのIAMロールのIAMポリシーにセッションマネージャーのログのS3保存向けで以下のように設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::SSM用のS3バケット名/*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetEncryptionConfiguration",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": "arn:aws:s3:::SSM用のS3バケット名",
            "Effect": "Allow"
        }
    ]
}

CloudWatchLogsの暗号化「KMS キー ID（正確にはKMSのキーARN）」を正しく設定する。既存のCloudWatchLogグループは、AWS CLIを使わないとKMSキーによる暗号化出来ないです。CloudWatchロググループをKMSで暗号化にてご確認ください。

AWS Systems Manager→セッションマネージャー→設定→編集→CloudWatch logging→enableにチェック→Allow only encrypted CloudWatch log groupsにチェック→「リストからロググループを選択する」にチェック→CloudWatchロググループを選ぶ→該当するロググループをチェック→右下のオレンジ色の「保存」をクリック、という感じでSSMのCloudWatch設定を見直す。

カテゴリー
AWS

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

AWS

前の記事

amazon-cloudwatch-agentのインストールとAmazonLinux2のログとメモリ・ディスク使用率のCloudWatch設定
2020年10月7日
AWS

次の記事

PowershellでAWS CLIを打って地味にミスった書き方など
2020年10月8日