こんにちは、今日もブログをかいていきます。最近というか一回もかいたことないかもですが、AWS でのちょっとした困ったことがあったので、それをブログにしたいと思います。
みなさんCloudshell 使っていますか？僕はわりと好きなので、たまに使ったりします。コンソールにIP 制限とかもかけてますか？セキュリティを向上させるために、ちょっとやってみたことが実は。。。ということがたまにあります。
今回はその内容について紹介したいと思います！！
IP 制限をかけるとCloudshell でAccess denied が出た
IP 制限をしようと思い、下記のようなpolicy を書きました。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"xxx.xxx.xxx.xxx/32"
]
}
}
}
}そして、何気なくCloudshell を叩くと、なんかAccess denied されてしまいました。
aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:iam::xxxxxxxxxxxx:user/test-user is not authorized to perform: s3:ListAllMyBuckets with an explicit deny in an identity-based policy今回IP 制限しかしてなかったので、原因はこれで間違いなかったのですが、理由はなんだったんでしょうか。
Cloudshell が実行されるIP ??
どうも調べてみると、Cloudshell が実行されるIP が違うということがわかりました。自分のコンソールで実行しているので、自分のIP が許可されていれば大丈夫かと思っていたのですが、どうもそうではないようです。
なので、IP 制限でもすり抜けるようにする必要があります。ということで以下の記述を加えてあげます。
"StringNotLike": {
"aws:userAgent": "*exec-env/CloudShell*"
}これをCondition の条件の中にいれてあげましょう。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"xxx.xxx.xxx.xxx/32"
]
},
"StringNotLike": {
"aws:userAgent": "*exec-env/CloudShell*"
}
}
}
}そして、もう一度Cloudshell でCLI を実行すると上手くいきます。Cloudshell はIP 制限によって、使えなくなってしまいますが、ローカルでAWS CLI を実行することはできるので、ローカル実行に関しては気にしなくていいそうです。
なので、Cloudshell使いたいけど、IP 制限解除できないし、ポリシー変更できないなーっていう場合は、ローカルに逃げるというのは選択肢として大いにありかなと思います。
参考
コメント