このブログを検索

ラベル AWS の投稿を表示しています。 すべての投稿を表示
ラベル AWS の投稿を表示しています。 すべての投稿を表示

2019/10/02

SSMエージェントをインストールできない話

インスタンス作成時にRHEL7にSSMエージェントを入れる場合、ユーザーデータで下記のコマンドを実行するよう指定されている。
#!/bin/bash
cd /tmp
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl start amazon-ssm-agent
ただし、このコマンドだと一度s3.amazonaws.comというグローバルアドレスを参照しに行ってしまうため、
NATゲートウェイを使ってなかったりでインターネットから切り離した環境ではインストールできない。

その場合はS3エンドポイントを有効にして、インスタンスと同じリージョンのS3を見に行くように明示的にURLを指定する。
#!/bin/bash
cd /tmp
sudo yum install -y
https://s3.(リージョン).amazonaws.com/amazon-ssm-(リージョン)/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl start amazon-ssm-agent
一応ガイドの最後に書いてあるんだけど、どういうときに使うかが書いていないので備忘。

2019/09/27

VPCエンドポイントにハメられる話

メモ

AWSのPrivateサブネットからいい感じに他のAWSサービスを利用する方法として、VPCエンドポイントがある。

SSMエージェントを使用する時に要求されるエンドポイント4つ(ssm,ec2,ssmmessage,ec2message)の中で、
なぜかssmのエンドポイントだけap-northeast-1d(apne-az2)のサブネットに置けないという謎仕様があった。
サポートに問い合わせてもできないとのことだったので、
特定のサブネットにエンドポイントを置きたい場合は注意が必要。

他のサブネットに置いてもプライベートDNSを有効にしとけばサブネット跨ぎでエンドポイントは利用できるみたいだから、
CIDRブロックをガチガチに管理してるような環境じゃなければ気にしなくても良いと思うけど。

2019/9/27現在、ssmエンドポイント以外にも、SFTP Transfer for S3のエンドポイント2種もapne1dで使えなかった。あと2つぐらいあった気がする。
2020/3/25に確認したところ、ssmエンドポイントはapne1dでも使えるようになってました。

2019/09/25

AWSのリソースポリシーの話

メモ。

AWSの権限管理と言えばIAMポリシーだけれど、S3バケットやAPI Gatewayにはリソースポリシーがある。

IAMポリシーは明示的にAllowされている権限だけが付与されるが、
リソースポリシーは明示的にDenyされていない限り同一アカウントからのアクセスは受け入れてしまう。
従ってリソースにホワイトリスト形式でIPアドレス制限をかけたい場合などは、下記リンクのようにDenyで全てのアクセスを拒否した上で、Condition句にNot条件を書く必要がある。

これと同様の方法で、例えばTrustedAdvisorに付与したIAMロールをホワイトリストで許可したい場合は、StringNotLike条件でuserid:*を記述する方法がある。

ただ、useridはブラウザコンソールから簡単に確認できず、ARNに比べるとどのIAMロールを指しているかがとても分かりにくいのが難儀。
色々試してみたところ、ArnNotEquals条件にPrincipalArnを記述すれば同じ効果が得られそうだった。
"Condition":{
  "ArnNotEquals":{
    "aws:PrincipalArn": "aws:arn:111122223333:role/role-name"
  } 
}
SourceArn条件だとアクセス元のAWSサービスのARNを指定することになるみたい。(Lambdaとか)