このアクション、タグベースの認可 ないし リソースレベルのアクセス許可 に対応してる? IAM ポリシービジュアルエディタでお手軽に確認しちゃおう

このアクション、タグベースの認可 ないし リソースレベルのアクセス許可 に対応してる? IAM ポリシービジュアルエディタでお手軽に確認しちゃおう

IAM のアクションが対応しているリソースタイプ、条件キーを網羅的に確認するのはリファレンスが便利ですが、ちょっとした確認にはビジュアルエディタも便利です。
Clock Icon2020.06.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉(幸)です。

私は AWS を触り始めてからかれこれ5年ほど経とうとしていますが、これまで IAM ポリシーを作成する際には「それっぽいベースを拾ってきてからの気合の JSON 直編集一本勝負」でしか闘ってきませんでした。それしか知らなかったのです。

正確に言うとビジュアルエディタという存在自体は知っていたのですが、「そんなハイカラなものは私には合わないであろうきっと」、その一心で使うのを避けてきました。

このたび戯れにビジュアルエディタを触ってみたところ、意外と便利ではこれは……という思いに駆られたので、どこに嬉しさポイントがあるのかを記していきます。

目次

IAM ポリシーのビジュアルエディタ とは

IAM ポリシーをマネジメントコンソールから作成・編集する際に選択できるオプションです。

いつから使えたんだっけ?と思い調べると、2017年に登場した機能のようです。(こういう時に Developers.IO というメディアには何でも載ってるなァという思いに駆られます。)

使い方のイメージは上記エントリをご参照ください。

タグベースの認可 とは

以下のイメージです。

AWS リソースにはタグを付与することができます。タグはキーと値の組み合わせからなります。

AWS リソースに対してアクションを実行するエンティティとして IAM ユーザーとロールが存在します。エンティティには IAM ポリシーをアタッチすることでアクションの実行に必要な権限を付与することができます。

ここで、一部のアクションは「対象のリソースに特定のタグが付与されている場合のみ実行可能」という条件を追加することが可能です。この条件づけが可能なことを、「タグベースの認可」に対応していると言います。

リソースレベルのアクセス許可 とは

以下のイメージです。

AWS リソースは一意に識別可能な ARN を持っています。 ARN の書式は以下のいずれかとなります。

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

例えば、以下の条件のインスタンスがあるとします。

  • AWS アカウント : 111122223333
  • リージョン : us-east-1
  • EC2 インスタンスID : i-xxxxxx

このリソースの ARN は以下のように表されます。

arn:aws:ec2:us-east-1:111122223333:instance/i-xxxxxx

同一のリージョンに存在する全てのEC2インスタンスは以下のように表現できます。

arn:aws:ec2:us-east-1:111122223333:instance/*

このように、特定のリソースID、あるいはリソースタイプをアクションの実行対象として指定できることを「リソースレベルのアクセス許可」に対応している、と言います。

主に参照系( List や Describe など)のアクションはこれに対応しておらず、「全てのリソースを対象」という指定の仕方をする必要があります。

ビジュアルエディタを使うと嬉しいところ

ここまで見てきた「タグベースの認可」「リソースレベルのアクセス許可」もそうですが、嬉しさを理解するために必要となる前提の知識があります。

IAM リファレンスの AWS のサービスのアクション、リソース、および条件キー - AWS Identity and Access Management の読み方を知っていることです。

以下のエントリで基本的な読み方を記しているので、併せてご参照いただければと思います。

ここでは嬉しさポイントを以下に絞って紹介していきます。

  • 依存アクションの有無を確認できる
  • アクションが対応するリソースタイプを確認できる
  • アクションが対応する条件キーを確認できる

依存アクションの有無を確認できる

ますは依存アクションがわかる点です。依存アクションとは、一つのアクションが複数のリソースに対してアクセスするために、追加でアクセス許可を与えておく必要があるものです。

ビジュアルエディタの基本的な使い方と合わせて見ていきます。今回は新規ポリシーの作成時の画面を例に取ります。

まずはポリシーに追加するアクションが属するサービスを選択します。サービスは膨大な量があるため、サービス名のフィルタリングを活用するのがよいでしょう。

続いてアクションを選択します。アクションもアクション名でフィルタリングが可能です。また、アクセスレベルごとにまとまったアクションを表示・選択することも可能です。

表示されたアクションの隣の[?]アイコンをクリックすることで詳細が確認できます。もしアクションに依存アクションが存在する場合はこの画面で確認することができます。

アクションが対応するリソースタイプを確認できる

先ほどと選択するアクションを変えてみました。アクションがリソースレベルのアクセス許可に対応している場合、詳細画面から確認することができます。

リソースタイプは「必須」か「オプション」かに分けられますが、その区別もつくようになっています。

また、アクションを選択することで、その下のリソースセクションに、対応したリソースタイプが表示されます。必須のリソースタイプはオレンジで表されます。

ここでは、リソースを「全て("Resource": "*")」で指定するか、リソースタイプを個々に指定するかを選択することができます。後者を選択した場合、「必須」のリソースタイプを省略することはできません。

また、リソースタイプごとに ARN をカスタマイズすることができます。リソース ID を絞ることなく「リソースタイプすべて」を選択する場合は、画面右のチェックボックスを入れることで実現できます。 詳細にカスタマイズする場合は 「ARN の追加」を押下すれば以下のようなウィザードが開くため、簡単に作成することもできます。

アクションが対応する条件キーを確認できる

先述のエントリで説明した内容をおさらいしておくと、 AWS のサービスのアクション、リソース、および条件キー で確認できる条件キーは以下のような考え方になっています。

  • アクショに紐づく条件キー
    • アクションそのものに紐づく条件キー
    • アクションとリソースタイプの組み合わせに紐づく条件キー
  • リソースタイプに紐づく条件キー

両者の合算が条件キーテーブルに記載されています。

ここで、「★」がついている部分は、アクションの詳細ページで確認することができます。

また、「リクエスト条件」セクションで、「条件の追加」を押下することで、条件キーの追加画面に遷移することができます。

「条件キー」のプルダウンで表示されるのは、アクションに対応した条件キーの一覧です。「条件キーテーブル」で確認できるものは、ここでは「サービスレベルの条件キー」と表現されています。この例では、サービスレベルの条件キーとして以下があります。

  • 特定のアクションで使用できるグローバル条件キー(aws:から始まるもの)
  • サービス固有の条件キー(ec2:から始まるもの)

どのアクションでも使用できる条件キーはその上部で「グローバル条件キー」という括りで表示されます。両者のイメージは以下です。

「タグベースの認可」に使用できる条件キーは「サービスレベルの条件キー」にのみ存在します。「このアクションってタグベースの認可に対応してたっけ?」とふと分からなくなった時は、この箇所から確認することもできます。

終わりに

ビジュアルエディタを使った時の嬉しさポイントの確認でした。リファレンスの読み方が分かった後であれば、個々のアクションに対して確認が取れるのは便利かと思います。網羅的に確認したいのであればリファレンスで、 少数のアクションを手軽に確認したいのであればビジュアルエディタで、という使い分けができるのではないでしょうか。

また、ビジュアルエディタと JSON は交互に切り替えが可能なため、補完しながら使うことができます。ひとまず JSON で書いてみて、ビジュアルエディタに切り替えた時に何かエラーがでないか?といった確認の仕方もできそうです。とはいえ、完全に何でもできるというわけではなさそうなので、頼りすぎはやめておきましょう。

IAM ポリシーのトラブルシューティング - AWS Identity and Access Management

マネジメントコンソールに入らずにポリシーの生成ができる AWS Policy Generator というものもあるのですが、ビジュアルエディタほど嬉しさポイントは発揮されていませんでした。

用途に応じて使い分けてみてください。私は引き続き「それっぽいベースを拾ってきてからの気合の JSON 直編集一本勝負」メインで闘っていきます。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.