AWS Elemental MediaStoreのコンテナポリシーはオブジェクトのみを対象としているという話

AWS Elemental MediaStoreのコンテナポリシーはオブジェクトのみを対象としているという話

AWS Elemental MediaStoreのコンテナポリシーではコンテナ内のオブジェクトのみのアクセス制御を行い、コンテナ自身はアクセス制限の対象になりません。検証の際などに万が一ポリシー記述を誤っても容易にリカバリが可能です。
Clock Icon2021.08.31

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

はじめに

清水です。AWSのオブジェクトストレージサービスであるAmazon S3、アクセス制御を行う方法のひとつにS3バケットポリシーというものがあります。JSON形式のポリシードキュメントを用いて、S3バケットとオブジェクトに対するアクセス制御を行うことができます。このS3バケットポリシーを扱う際、アクセス権限を制限しすぎてS3バケット自体にアクセスできなくなったり、バケットポリシー自体変更ができなくなる、というのはよくあるパターンかと思います。rootユーザでのバケットポリシーの削除が必要なケースですね。私もヒヤッとしたのは1度や2度ではなく、バケットポリシー設定の(特に権限を絞る)場合には細心の注意を払っています。

ところで、AWSにはS3とよく似たサービスとしてAWS Elemental MediaStoreというものがあります。ここではサービスの詳細は割愛しますが *1、MediaStoreにもバケットポリシーとよく似たコンテナポリシーというものがあり、オブジェクトに対するアクセス制御を行うことが可能です。ここでポイントなのが、MediaStoreのコンテナポリシーについては オブジェクトに対する アクセス制御を行い、コンテナ(S3でいうバケット)に対するアクセス制御は行なえません。つまり、ポリシーの設定をミスしてもポリシーの編集権限自体は残るため、rootユーザでポリシーを削除するといったことが不要です。気を楽にしてアクセス制御ポリシーの編集ができるかと思います。(特に検証を行う場合ですね。本番環境に対する設定変更作業は気を引き締めて行いましょう。)本エントリではこのMediaStoreのコンテナポリシー編集時、うっかりすべての操作をDenyしてしまった場合の挙動を確認してみます。

MediaStoreのコンテナポリシーをすべての操作をDenyするような設定をしてみた

それではMediaStoreのコンテナポリシーですべての操作をDenyするような設定を行ってみたいと思います。MediaStoreのコンテナポリシー詳細はユーザガイドの以下などを参照ください。

本エントリではざっくりと「すべての操作をDeny」するような設定としていますが、実際にはIPアドレス制限を行う場合にIPアドレスの指定をしくじってしまった、などが現実的にありえるケースかと思います。

まずはMediaStoreコンテナを作成、デフォルトとして設定されているポリシーを確認してみましょう。以下のポリシーが設定されています。

{
	"Version": "2012-10-17",
	"Statement": [{
		"Sid": "MediaStoreFullAccess",
		"Action": [ "mediastore:*" ],
		"Principal": {"AWS" : "arn:aws:iam::123456789012:root"},
		"Effect": "Allow",
		"Resource": "arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer/*",
		"Condition": {
			"Bool": { "aws:SecureTransport": "true" }
v		}
	}]
}

これに対して編集を行っていきますが、その前に、確認用にファイルを1つアップロードしておきます。before-policy-edit.htmlという名称のファイルにしました。以下のように、MediaStoreマネジメントコンソールからItemsの項目で確認が行なえます。(下段は編集前のコンテナポリシーです。)

続いて、コンテナポリシーを編集してみましょう。ポリシーは以下の内容とします。"Principal": "*"に対してmediastore:*なすべてのアクションをDenyしています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllAccess",
            "Effect": "Deny",
            "Action": "mediastore:*",
            "Principal": "*",
            "Resource": "arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer/*",
            "Condition": {
                "Bool": { "aws:SecureTransport": "true" }
            }
        }
    ]
}

設定後、 反映のために5分待ちます。 これはユーザガイド「コンテナポリシーを編集する」にある通り、MediaStoreではコンテナポリシーを編集して新しいポリシーが有効になるまで最大で5分かかるためです。

5分経過したら、マネジメントコンソールを開いているブラウザを更新してみましょう。先ほどアップデートしておいたファイルbefore-policy-edit.htmlが消えていますね。これはMediaStoreコンテナ自体から消えたのではなく、(わかりにくいですが)このマネジメントコンソールを表示しているIAMユーザから参照権限がなくなった状態となります。

この確認のため、rootユーザでマネジメントコンソールにログイン、このMediaStoreコンテナを表示してみましょう。以下のように、before-policy-edit.htmlが表示されます。

また同様に、IAMユーザの場合は新たなファイルのアップロードもできません。コンテナポリシーで設定した通り、指定したコンテナ内のすべてのオブジェクトarn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer/*に対して、Denyされている状況です。

しかし、コンテナ自体や、各ポリシーの参照や編集は可能です。というのも、先ほどのポリシーでのResourceの指定のしかたはMyContainer/*という形式でした。S3のバケットポリシーでもそうですが、末尾に/*とついていれば、そのバケット/コンテナ内のオブジェクトに対する操作、ということになりそうです。それでは、このコンテナポリシーでコンテナ自体を指定するよう、Resourceをarn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainerと末尾の/*を省いて設定しようとしてみます。以下のポリシー内容です。

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Sid" : "DenyAllAccess",
    "Effect" : "Deny",
    "Principal" : "*",
    "Action" : "mediastore:*",
    "Resource" : "arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer",
    "Condition" : {
      "Bool" : {
        "aws:SecureTransport" : "true"
      }
    }
  } ]
}

[Save]ボタンを押下しますが、以下のようなエラーが出てしまいました。

ValidationException: Invalid Container Policy: Resource in statement 'DenyAllAccess' must be scoped to files inside arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer

Resourceはあくまでファイル(=オブジェクト)に対して指定する必要がある、ということですね。

なお、マネジメントコンソールではなくAWS CLIから操作した場合でも同様のエラーが発生します。(なのでマネジメントコンソールでポリシー内容をチェックしているわけではなさそうです。)

$ aws mediastore get-container-policy --container MyContainer
{
    "Policy": "{\n  \"Version\" : \"2012-10-17\",\n  \"Statement\" : [ {\n    \"Sid\" : \"DenyAllAccess\",\n    \"Effect\" : \"Deny\",\n    \"Principal\" : \"*\",\n    \"Action\" : \"mediastore:*\",\n    \"Resource\" : \"arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer/*\",\n    \"Condition\" : {\n      \"Bool\" : {\n        \"aws:SecureTransport\" : \"true\"\n      }\n    }\n  } ]\n}"
}
$ cat policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllAccess",
            "Effect": "Deny",
            "Action": "mediastore:*",
            "Principal": "*",
            "Resource": "arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer",
            "Condition": {
                "Bool": { "aws:SecureTransport": "true" }
            }
        }
    ]
}
$ aws mediastore put-container-policy --container MyContainer --policy file://policy.json

An error occurred (ValidationException) when calling the PutContainerPolicy operation: Invalid Container Policy: Resource in statement 'DenyAllAccess' must be scoped to files inside arn:aws:mediastore:ap-northeast-1:123456789012:container/MyContainer

まとめ

AWS Elemental MediaStoreのコンテナポリシーがコンテナ自身のアクセス制御は行わず、コンテナ内のオブジェクトに対してのアクセス制御にのみ使用されることを、すべての操作をDenyするようなポリシーを設定して確認してみました。もしコンテナポリシー内容を誤ってしまい意図しないアクセス制御を行った場合でも、ポリシー自体の操作などコンテナ操作は対象外になります。rootユーザでリカバリをするといった必要がなく、気楽に検証などができるかと思います。とはいえ、ポリシー設定時にはその内容をよく理解、確認して行うようにしましょう。

脚注

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.