![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
右上の「認証情報」メニューからユーザーを選択すると一覧
とても多いので覚えていられない。デフォルトでは何の権限もないとのこと。
「デフォルト設定では、ユーザーは何もできず、そのユーザーのアクセスキーを参照することすらできません。ユーザーに何かの操作をするアクセス権限を付与する場合には、ユーザーにアクセス権限を追加する（つまり、ポリシーをユーザーに関連付ける）か、ユーザーを該当のアクセス権限を持つグループに追加します。」
http://blog.serverworks.co.jp/tech/2014/02/07/iam-ec2/
CloudWatchのAPIを利用するので、「CloudWatch Read Only Access」権限のあるIAM roleをもったインスタンスにしてください。 カスタムメトリックを作成する場合は、CloudWatchの「PutMetricData」を許可するようにします。
http://stk-inc.co.jp/2013/01/aws-cloudwatch-ec2/
ユーザやグループ、ロール、リソースにアクセス許可を割り当てるには、ポリシーを作成します。ポリシーはアクセス許可を明示的にリスト化したドキュメントです。
AWS 管理ポリシーはAWS側が提供しているポリシーでAWS要因で変更される可能性がある。 管理ポリシーとインラインポリシーの違いは、管理ポリシーは複数のエンティティに付与可能。インラインポリシーはその内部のみ。変更管理や複数割り当てができるので管理ポリシーにしておくべし！
| AWS Managed Policy | Amazonが管理しているポリシー。勝手に変更される可能性があるが個人レベルの実験ならこれを割り当てておけ！ |
| Customer Managed Policy | ユーザーが自由に設定できる管理ポリシー |
| Inline Policy | 個別で設定するポリシー。共有不可能 |
３つあるが、定義できることに違いはない。 AWS管理ポリシーにはAmazonS3FullAccessなどサービス名FullAccessなど一目見てわかるものが多い。
| Effect | AllowかDenyだが、基本Allowしか書かない |
| Action | 操作内容。対象:アクションのように記載。S3ならs3:Get*,s3:List* |
| Resource | 対象となるリソース。awsの独自表記でS3ならarn:aws:s3:::* |
ユーザーとグループは一般的なものと一緒。ロールはちょっと特殊でEC2インスタンスにアタッチすることによりシークレットキーなしでアクセスできる。
普通にユーザーにIP制限すると、うまくいかない。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRestriction",
"Action": [
"ec2:*"
],
"Effect": "Deny",
"Resource": [
"*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "58.0.96.28/32"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
}
]
}
上記でEC2に関しては、IP制限がきいた。しかしS3などを追加するとそこはどこのIPからもいけてしまう。
