Elastic Beanstalkを使うときのIAM policy設定

最近ちょっとした検証環境とか、小さいアプリをデプロイするのにElastic Beanstalk*1をつかってる。サーバセットアップの手間も省けるし、HTTPで叩ける小さなAPIとかだと手軽にデプロイできるので便利。

AWS Elastic Beanstalk（アプリケーションのデプロイ・管理用コンテナ） | アマゾンウェブサービス (AWS 日本語) http://aws.amazon.com/jp/elasticbeanstalk/

ただ、微妙に付与する権限が手広くなりがちなので調整したいと思っている。

参考: Using IAM Roles with AWS Elastic Beanstalk - AWS Elastic Beanstalk http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.iam.roles.aeb.html

基本的にはこの権現でいいと思う。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticbeanstalk:*",
        "ec2:*",
        "elasticloadbalancing:*",
        "autoscaling:*",
        "cloudwatch:*",
        "s3:*",
        "sns:*",
        "cloudformation:*",
        "rds:*",
        "iam:AddRoleToInstanceProfile",
        "iam:CreateInstanceProfile",
        "iam:CreateRole",
        "iam:PassRole",
        "iam:ListInstanceProfiles"
      ],
      "Resource": "*"
    }
  ]
}

RDSを使わない場合などはrds権限はなくても良い。それと、アカウントごとに設定を絞ってもいい。

・・・とはいえ権限がこれだと広すぎて怖いので、もうちょっとこうなったらいいなと思うところはある。

削除系の権限をElastic Beanstalkで作成したResourceのみに制限したい
- 既存環境のDeleteも可能な広い権限になってしまうため
- ec2:*とか渡したくない

hakoberaさんの hakobera/ebfly (https://github.com/hakobera/ebfly) とか、Thought WorksのThoughtWorksStudios/eb_deployer (https://github.com/ThoughtWorksStudios/eb_deployer) もあるし、手軽にデプロイしたい環境が欲しいケースにはおすすめ。

ちなみにBeanstalkだとログの回収がネックになることも。そういう場合にはBeanstalkノードにFluentdをいれれば良さそう。うちではまだ試してないけど、細かい調整せずにaggregatorノードに送るだけ、というのならよいかも。

treasure-data/elastic-beanstalk-td-agent https://github.com/treasure-data/elastic-beanstalk-td-agent

*1:永遠のベータとの噂もある

すずけんメモ

技術メモです

Elastic Beanstalkを使うときのIAM policy設定