はじめに

IAM APEとは、Orca Security社がOSSで公開しているAWS IAMに対するツールです。

リポジトリはこちら。

AWS IAMユーザーやグループに権限を付与・制限するには、IAM自体でのアタッチ、Boundaryによる制限、SCPによる制限があります。
また、IAMユーザーは所属するグループの権限を引き継ぎます。
図で表すとこのような形で、３者全てで許容されていることのみが、対象のIAMリソースに許容されます。

例えば、特定のIAMユーザーで現在許容されていることは何なのかを確認するためには、BoundaryやSCP、自分自身およびグループ、それぞれに設定されたポリシーを確認して回る必要があります。
結構、複雑になっていることもあります。そこでIAM APEの出番です。IAM APEによって、整頓することができます。

IAM APEは以下の流れで実行されます。

  • Collect
  • Expand
  • Evalute
  • Report

指定した対象（IAMユーザーやグループなど）に対し、集約した結果を出力してくれます。

IAM APEの実行

何はともあれ実行してみましょう！

インストールはpipで可能です。
まずは、updateすることが推奨されていますので実行します。

それでは、実行してみます。
実行には、プロファイルを指定して直接AWSアカウントから情報を収集するか、予め結果をファイルに落としておいてインプット情報として渡します。

コマンドはこんな感じになります。都度読み込みは時間がかかるのでインプットでファイル渡しが効率的ですが、今回はいろいろ条件を変えながら実施したいのでプロファイル指定を利用しました。

 $ iam-ape --arn arn:aws:iam::123456789012:user/test-user01 --profile default
 $ iam-ape --arn arn:aws:iam::123456789012:user/test-user01 --input ./input.txt

検証用のテストユーザーを作成します。
作成したユーザーは、S3の特定のバケットにのみ読み書き権限を持つグループにアサインしておきます。

結果はこんな感じです。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::TEST-BUCKET",
        "arn:aws:s3:::TEST-BUCKET/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

次に、テストユーザーに直接ポリシーをアタッチしてみます。EC2のReadOnlyを付けてみます。
結果はこんな感じになりました。EC2のReadOnly権限が追加されたことが確認できます。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:Describe*",
        "cloudwatch:Describe*",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:Describe*",
        "elasticloadbalancing:Describe*"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::TEST-BUCKET",
        "arn:aws:s3:::TEST-BUCKET/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

今度は同様に、S3のフル権限をアタッチしてみます。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::TEST-BUCKET",
        "arn:aws:s3:::TEST-BUCKET/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:Describe*",
        "cloudwatch:Describe*",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:Describe*",
        "elasticloadbalancing:Describe*",
        "s3-object-lambda:*",
        "s3:*"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

先ほどのEC2の記述に追記されました。
期待値としては、グループでの記述（特定のバケットのみへの権限）が消えて欲しかったですが、それは望み過ぎか。

最後にバウンダリーを追加してみます。
S3のReadOnlyのバウンダリーを設定してみます。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3-object-lambda:Get*",
        "s3-object-lambda:List*",
        "s3:Get*",
        "s3:Describe*",
        "s3:List*"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:Describe*",
        "s3:List*"
      ],
      "Resource": [
        "arn:aws:s3:::TEST-BUCKET",
        "arn:aws:s3:::TEST-BUCKET/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

おお！！
バウンダリーによって制限されたEC2への権限が消えたことにより、より可読性が上がりました。

まとめ

AWSを運用していて、権限エラーが発生した際に原因を探し回ったり、Boundaryに気付けず無駄に権限を広げてみたりしたことはないでしょうか？
私はあります。

IAM APEは手軽に扱うことができ、環境に変更なくチェックできる便利なツールです。
権限設定で確認したいことができた時は一度お試しあれ！