はじめに
清水です。先日、Low-Latency HLS (LL-HLS)に対応したAWS Elemental MediaPackage v2がリリースされました。
本DevelopersIOでも下記エントリで速報済みです。
さて上記の速報エントリでは、MediaLiveと連携してMediaPackage v2の注目機能であるLL-HLSでのライブ配信を行うまでのリソース作成を急ぎ確認してきました。本エントリではそのほかのMediaPackage v2の機能として、2つのPolicyについて確認してみたいと思います。
MediaPackage v2は「使いやすさとセキュリティが向上し、LL-HLSをサポートした」と謳っています。このセキュリティに当たる部分の役割を担っているのが、新たに利用可能になったChannel policyとEndpoint policyです。2つのポリシーそれぞれで、MediaPackage v2のどの部分を保護するのか、どういったPolicyの記述方法があるかなどを確認していきます。
Ingestを保護するChannel policy
まずはChannel policyです。Channel group作成後、そのChannel groupに紐付くChanelを作成する際に指定が可能です。
ChannelリソースのPolicyタブでも内容の確認や設定が可能です。
Channel policyの用途としてはマネジメントコンソールにも表記があるとおり、MediaPackageを有するAWSアカウント以外からMediaPackageのChannelにIngestする場合に割り当てるというかたちです。
MediaPackageと同じAWSアカウントのAWS Elemental MediaLiveを利用する場合はChannel policyを設定する必要はありません。（Policyをアタッチしない「Don't attach a policy」を選択します。先日の速報エントリではこの設定を使用しました。）
MediaPackage v2 User Guideには「Ingest authorization」としてまとめれられています。
MediaPackageと別AWSアカウントのAWS Elemental MediaLiveのほか、AWS Elemental LiveやAWSの認証に対応したサードパーティ製のエンコーダ製品などがChannel Policyと連携して機能します。別AWSアカウントのMediaLiveでは、そのMediaLiveで使用するIAMロールに対して許可を与え、またAWS Elemental Liveとサードパーティ製エンコーダではIAMユーザを作成し、そのIAMユーザのアクセスキーIDとシークレットキーを使ってMediaPackage v2にアクセスする、というぐあいですね。
Channel policyを使ってでクロスアカウントでMediaPackageを使ってみる
実際にMediaPackageとは別のAWSアカウントのMediaLiveから、Channel Policyを設定したMediaPackage v2へIngestする動作を確認してみましょう。
別AWSアカウントのMediaLiveの準備
MediaPackageを有するものとは別のAWSアカウントでMediaLiveリソースを準備します。こちらのブログエントリと同様の設定としました。（なお、MediaLive Channelで利用するIAMロールを設定する際、そのIAMロールで内容のUpdateが未実施であれば実施しておきましょう。mediapackagev2:PutObjectのアクション許可が追加されていることが必要です。）
MediaLive ChannelのOutput GroupsのHLS group destinationには、（MediaLiveとは別のAWSアカウントの）MediaPackage v2のChannelリソース、SettingsのタブのHLS ingest endpointを入力します。Credentialsについては空欄の状態です。
Channel Policyをアタッチしていない場合
MediaLive Channelが作成できたら、まずはMediaPackage側のChannel Policyをアタッチしていない場合の挙動を確認しておきましょう。MediaLive ChannelをStartさせ、OBS Studioから映像を打ち上げます。しばらくすると以下のようにMediaLive側でたくさんのAlertsが発生しました。出力先となるMediaPackageへ書き込みが行えない状態ですね。当然、MediaPackage側のmanifest URLを参照しても最新のライブストリーミングは再生できません。
クロスアカウント用のChannel Policyを設定
続いてMediaPackageのChannel Policyを設定して、クロスアカウントでMediaLiveからMediaPackageが利用できるようになることを確認してみます。
MediaLive Channelをいちど停止し、MediaPackage v2 User Guideにならい以下のPolicyをMediaPackageのChannel policyとして設定します。
{
"Version": "2012-10-17",
"Id": "AllowMediaLiveChannelToIngestToEmpChannel",
"Statement": [
{
"Sid": "AllowMediaLiveRoleToAccessEmpChannel",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[MediaLiveのAWS AccountID]:role/MediaLiveAccessRole"
},
"Action": "mediapackagev2:PutObject",
"Resource": "arn:aws:mediapackagev2:[Region]:[MediaPackageのAWS AccountID]:channelGroup/[ChannelGroupName]/channel/[ChannelName]"
}
]
}
改めてMediaLive ChannelをStartし映像を打ち上げ、MediaPackageのEndpoint、Manifest URLから確認してみましょう。今度はライブストリーミングの視聴ができました！
Egressを保護するEndpoint policy
続いてはEndpoint policyです。Channelリソース作成後にOrigin endpointを作成する際、設定項目が現れます。
Origin endpointリソースの詳細画面、Policyタブで内容の確認や編集が可能です。
Endpoint policyはその名前の通り、動画再生時のManifestやSegmentのURLを保護します。MediaPackageを利用して動画配信をする場合、通常はAmazon CloudFrontなどCDNを経由してエンドユーザに配信します。Origin EndpointはCDNからのアクセスのみを許可するなどして保護する必要がありますよね。さらにライブストリームの監視などで特定の条件を満たすクライアントに対してはアクセスを許可する、といった必要もあります。これらがEndpoint policyを利用して実現可能になるわけです。
MediaPackage v2 User Guideには「Origin endpoint authorization」としてポリシー例がまとめられています。
アクセスキー、シークレットキーによる認証に対応しているサードパーティCDNに対してIAMユーザを用いて認証する例のほか、AWS認証をサポートしていない場合の保護方法としてIPアドレスによるアクセス制限の例などが記載されています。（ただし、2023/05/31の時点で確認する限り、肝心なCloudFrontとの連携方法についてはMediaPackage v2 User Guideやマネージメントコンソールには記載がありませんでした。AWS Elemental MediaStoreも対応しているCloudFrontのOrigin Access Control (OAC)でMediaPackage Originへのアクセスが許可されるのが理想的ですが、アップデートを待ちたいと思います！）
なお、先日の速報エントリでは検証用途としてパブリックアクセスを許可する「Attach a public policy」を選択しました。以下のポリシーが設定さていたぐあいです。User Guideにも「Anonymous access」として記載されています。
{
"Version": "2012-10-17",
"Id": "AnonymousAccessPolicy",
"Statement": [
{
"Sid": "AllowAnonymousAccess",
"Effect": "Allow",
"Principal": "*",
"Action": "mediapackagev2:GetObject",
"Resource": "arn:aws:mediapackagev2:[Region]:[AccountID]:channelGroup/[ChannelGroupName]/channel/[ChannelName]/originEndpoint/[OriginEndpointName]"
}
]
}Endpoint policyによるIPアドレス制限を試してみる
実際のEndpoint policyの活用例として、IPアドレスによるEndpointのアクセス制限を試してみましょう。User Guideの「Restrict access by IP range」を参考に、以下のPolicyをMediaPackage Origin Endpointに設定しました。
{
"Version": "2012-10-17",
"Id": "IpRangePolicy",
"Statement": [
{
"Sid": "RestrictByIpRange",
"Effect": "Allow",
"Principal": "*",
"Action": "mediapackagev2:GetObject",
"Resource": "arn:aws:mediapackagev2:ap-northeast-1:123456789012:channelGroup/mediapackage-v2-channel-group/channel/mediapackage-v2-channel/originEndpoint/mediapackage-v2-origin-endpoint",
"Condition": {
"IpAddress": {
"aws:SourceIp": "XXX.XXX.XXX.XXX/32"
}
}
}
]
}
指定したIPアドレスからHLS manifestのURLにアクセスしてみます。アクセスに成功してmanifest fileの中身が確認できますね。
% curl -i https://xxxxxx.egress.xxxxxx.mediapackagev2.ap-northeast-1.amazonaws.com/out/v1/mediapackage-v2-channel-group/mediapackage-v2-channel/mediapackage-v2-origin-endpoint/hls-index.m3u8
HTTP/2 200
date: Wed, 31 May 2023 10:22:05 GMT
content-type: application/vnd.apple.mpegurl
content-length: 382
x-amzn-requestid: aaxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx36
x-amzn-mediapackage-endpoint-id: mediapackage-v2-origin-endpoint
access-control-allow-origin: *
x-amzn-mediapackage-channel-uniqueid: f310xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x-amzn-mediapackage-endpoint-uniqueid: 2a85xxxxxxxxxxxxxxxxxxxxxxxxxxxx
cache-control: max-age=3
access-control-expose-headers: x-amzn-requestid,x-amzn-errortype,x-amzn-mediapackage-last-sequence,x-amzn-mediapackage-last-updated,Date
x-amzn-mediapackage-active-input: 1
x-amzn-mediapackage-channel-id: mediapackage-v2-channel
access-control-allow-credentials: true
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:CODECS="avc1.640028,mp4a.40.2",AVERAGE-BANDWIDTH=5711200,RESOLUTION=1920x1080,VIDEO-RANGE=SDR,FRAME-RATE=30.0,BANDWIDTH=5931200
hls-variant_1.m3u8
#EXT-X-STREAM-INF:CODECS="avc1.64001F,mp4a.40.2",AVERAGE-BANDWIDTH=3511200,RESOLUTION=1280x720,VIDEO-RANGE=SDR,FRAME-RATE=30.0,BANDWIDTH=3643198
hls-variant_2.m3u8Endpointへのアクセスが許可されていない、指定したIPアドレス以外の環境からアクセスしてみます。403が返り、アクセスが拒否されました。
$ curl -i https://xxxxxx.egress.xxxxxx.mediapackagev2.ap-northeast-1.amazonaws.com/out/v1/mediapackage-v2-channel-group/mediapackage-v2-channel/mediapackage-v2-origin-endpoint/hls-index.m3u8
HTTP/2 403
date: Wed, 31 May 2023 10:22:43 GMT
content-type: application/json
content-length: 28
x-amzn-requestid: 86xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx94
access-control-allow-origin: *
x-amzn-errortype: AccessDeniedException
access-control-expose-headers: x-amzn-requestid,x-amzn-errortype,x-amzn-mediapackage-last-sequence,x-amzn-mediapackage-last-updated,Date
access-control-allow-credentials: true
{"Message":"Access denied."}MediaPackage v1との比較
MediaPackage v2でIngestを保護するChannel policy、ならびにEgressを保護するEndpoint policyそれぞれについて確認してきました。ここで、MediaPackage v1ではどのような保護設定があったか、簡単に振り返っておきましょう。
Ingestの保護はDigest認証
MediaPackage v1でのIngestの保護は、Digest認証により行われていました。マネジメントコンソールからDigest認証用のUsername/Passwordの確認ができますね。MediaPackage v1 User Guideの「Live supported codecs and input types 」にもWebDAVでDigest認証を使う旨の記載があります。
そのためMediaPackage v1には認証情報のローテーション機能が準備されています。（Rotating credentials on an input URL - AWS Elemental MediaPackage）またMediaLive、MediaPackageのリリース当時はMediaLive側でMediaPackageのIngest URL用の認証情報を設定していました。（【やってみた】AWS Elemental MediaLiveとAWS Elemental MediaPackageでライブ配信してみた #reinvent | DevelopersIO
なお、現在のようにMediaLive側でMediaPackageのChannel IDのみを指定することで連携が可能になったのは2019年3月からです。（[アップデート] AWS Elemental MediaPackageでCDN認証が利用可能になりエンドポイントが保護できるようになりました！ | DevelopersIO）この内部的な仕組みはMediaLive側IAMロールでmediapackage:DescribeChannelの権限を有し、DescribeChannelで取得できるDigest認証用のId、Passwordを用いてMediaPackageに接続している、と思われます。
% aws mediapackage describe-channel --id MediaPackageChannel1
{
"Arn": "arn:aws:mediapackage:ap-northeast-1:123456789012:channels/4be0xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"CreatedAt": "2018-04-29T16:09:16+00:00",
"Description": "MediaPackageChannel1",
"HlsIngest": {
"IngestEndpoints": [
{
"Id": "4be0xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Password": "1487xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Url": "https://573axxxxxxxxxxxx.mediapackage.ap-northeast-1.amazonaws.com/in/v2/4be0xxxxxxxxxxxxxxxxxxxxxxxxxxxx/4be0xxxxxxxxxxxxxxxxxxxxxxxxxxxx/channel",
"Username": "4a24xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
{
"Id": "d3b5xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Password": "5196xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Url": "https://f7b1xxxxxxxxxxxx.mediapackage.ap-northeast-1.amazonaws.com/in/v2/4be0xxxxxxxxxxxxxxxxxxxxxxxxxxxx/d3b5xxxxxxxxxxxxxxxxxxxxxxxxxxxx/channel",
"Username": "d17exxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
]
},
"Id": "MediaPackageChannel1",
"Tags": {}
}MediaPackage v2ではIAM連携したChannel PolicyでIngestの保護を行うかたちです。特にMediaLive連携では認証情報の管理は不要となり、よりセキュアに扱うことができますね。
Egressの保護はAccess control settings
MediaPackage v2でEndpoint policyによるEgressの保護ができるようになりましたが、MediaPackage v1ではAccess controlというEndpointの設定項目でEgressの保護を行っていました。マネジメントコンソールで確認すると以下のような設定項目ですね。
MediaPackage v1 User Guideには「Access control settings fields」の項目に記載があります。IPアドレスによるアクセス保護、ならびにCDN認証についてはMediaPackage v1でも実現自体はできていたかたちです。
ただし、CDN認証についてはCloudFrontのOrigin Access Identity (OAI)、もしくはOrigin Access Control (OAC)を使うようなかたちではなく、認証情報をAWS Secret Managerに格納しCloudFront側のOrigin Custom Headerでこの認証情報を設定するかたちでした。（[アップデート] AWS Elemental MediaPackageでCDN認証が利用可能になりエンドポイントが保護できるようになりました！ | DevelopersIO）
MediaPackage v2でEndpoint Policyによるアクセス保護が可能になったことで、IAMを用いたより柔軟なアクセス制御が期待できます。（特に期待したのはOACを用いたCloudFront連携ですが、先に述べたとおり2023/05/31現時点ではこちらが利用できるかの確認ができない状況です。アップデートに注目ですね！）
まとめ
AWS Elemental MediaPackage v2で利用できるChannel policy、Endpoint policyの2つのPolicyについて確認してみました。「使いやすさとセキュリティが向上」の謳い文句のとおり、これまで個別の設定だったアクセス保護設定がPolicyによる記述にまとめられています。IAMとの連携も強化されており、より使いやすくよりセキュアに利用が可能になっていますね。
Endpoint policyを用いたCloudFrontとの連携の部分が気になるところではありますが、引き続きAWS Elemental MediaPackage v2の各機能について、詳細を確認していきたいと思います。
3
