なぜこれが必要なのでしょうか？
- Igin（ツールとしてのインフラストラクチャ）の概念に関連するnginxツールを使用してファイルへのアクセスを制御します。 アクセスに関連するすべての変更は、プロジェクト内の構成でのみ行われます。
- nginxを介してファイルを提供する場合、それらをキャッシュし、S3へのリクエストを保存できます。
- このようなプロキシは、さまざまなアプリケーションのインストールでファイルストレージの種類を無視するのに役立ちます（結局、S3以外にも他のソリューションがあります）。
フレームワークを策定します
- ソースバケットはプライベートである必要があります-匿名ユーザーがS3から直接ファイルをダウンロードすることはできません。 あなたの場合、この制限が機能しない場合は、
proxy_pass
を使用するだけでproxy_pass
なくなります。 - 操作を簡素化するために、AWSによるチューニングは「チューニングして忘れた」ベースで1回だけ行う必要があります。
額に解決策を探しています
元のバケットが公開されている場合は、S3のプロキシリクエストなど、何も問題なく動作します。 プライベートの場合、どういうわけかS3で認証する必要があります。 インターネットの同僚は何を提供してくれますか：
- nginxを使用して認証プロトコルを実装する例があります。 ソリューションは優れていますが、残念ながら、 一部のAmazonデータセンターでは機能しない古い認証プロトコル（ Signature v2 ）向けに設計されています 。 たとえばフランクフルトでこのソリューションを使用しようとすると、 「指定した認証メカニズムはサポートされていません。」というエラーが表示されます。 AWS4-HMAC-SHA256を使用してください 。 」 プロトコルの最新バージョン（ Signature v4 ）は実装がはるかに困難ですが、nginxの既製のソリューションはありません。
- nginx- ngx_aws_auth用のサードパーティモジュールがあります。 ソースから判断すると、Signature v4をサポートしています。 ただし、プロジェクトは放棄されたように見えます。1年以上にわたってコードベースに変更はなく、開発者が応答しない他のモジュールとの互換性の問題もあります。 さらに、nginxに追加モジュールを追加することは、多くの場合、それ自体が苦痛なステップです。
- 別のs3プロキシを使用できますが、その多くはかなり書かれています。 個人的には、Goソリューション-aws-s3-proxyが気に入りました。これは、DockerHubで既製のかなり人気のあるイメージを持っています。 ただし、この場合、アプリケーションは潜在的な問題がある別のコンポーネントを取得します。
AWSバケットポリシーを適用する
原則として、AWSはその複雑さと大量のドキュメントで新しいユーザーを怖がらせます。 しかし、見れば、それは非常に論理的かつ柔軟に設計されていることを理解しています。 Amazonはまた、私たちのタスクであるS3バケットポリシーのソリューションを見つけました。 このメカニズムにより、クライアントまたはリクエストのさまざまなパラメーターに基づいて、バケットの柔軟な承認ルールを構築できます。
Policy Generatorインターフェイス-AWS Policy Generator
バインドできる興味深いオプションを次に示します。
- IP（
aws:SourceIp
）、 - Refererヘッダー（
aws:Referer
）、 - User-Agentヘッダー（
aws:UserAgent
）、 - 残りはドキュメントに記載されています 。
IPへのバインドは、アプリケーションに特定の居住地がある場合にのみ適切なオプションであり、現時点ではまれです。 したがって、他の何かに執着する必要があります。 解決策として、 秘密のUser-AgentまたはRefererを生成し 、秘密のヘッダーを知っているユーザーのみにファイルを提供することを提案します。 同様のポリシーは次のようになります。
{ "Version": "2012-10-17", "Id": "http custom auth secret", "Statement": [ { "Sid": "Allow requests with my secret.", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket-for-habr/*", "Condition": { "StringLike": { "aws:UserAgent": [ "xxxyyyzzz" ] } } } ] }
少し説明：
-
"Version": "2012-10-17"
は、編集する必要のないAWSインテリアキッチンです。 -
Principal
-このルールの影響を受ける人。 特定のAWSアカウントでのみ機能するように指定できますが、この場合は"*"
費用がかかります-これは、ルールが匿名ユーザーを含むすべてのユーザーに対して機能することを意味します。 -
Resource
-ARN（Amazon Resource Name）バケットおよびバケット内のファイルのテンプレート。 この場合、ポリシーはexample-bucket-for-habr
にあるすべてのファイルに適用されます。 -
Condition
-ポリシーが機能するために収束する必要のある条件は次のとおりです。 この例では、事前定義されたUser-Agentヘッダーをxxxyyyzzz
行と比較しています。
匿名ユーザーの観点から見たこのルールの動作は次のとおりです。
$ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt HTTP/1.1 403 Forbidden $ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt -H 'User-Agent: xxxyyyzzz' HTTP/1.1 200 OK
プロキシ用にnginxを設定することは残っています：
location /s3-media/ { limit_except GET { deny all; } set $aws_bucket "example-bucket-for-habr"; set $aws_endpoint "s3.eu-central-1.amazonaws.com:443"; set $aws_custom_secret "xxxyyyzzz"; proxy_set_header User-Agent $aws_custom_secret; rewrite ^/s3-media/(.*)$ /$aws_bucket/$1 break; proxy_buffering off; proxy_pass https://$aws_endpoint; }
おわりに
合計して、バケットの簡単なポリシーを作成すると、nginxを使用してファイルを安全にプロキシする機会が得られました。 ただし、IPに縛られておらず、追加のソフトウェアに依存していません。
PS
ブログもご覧ください。