Expand remote storage authentication example

[hguthrie]

Topic clarification/correction request

Topic Link

https://devdocs.magento.com/guides/v2.4/config-guide/remote-storage/config-remote-storage-aws-s3.html

Description

per Slack: i think we need to show a sample scenario for IAM and for the secret keys, separately, and in more depth.

Possible solutions

Possibly expand topic or create a new sub-topic with a generic example for including the Nginx ngx_aws_auth module for use with secret keys.

[m2-assistant[bot]]

Hi @hguthrie. Thank you for your report. To help us process this issue please make sure that you provided sufficient information.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[tdm4]

I have some suggestions to make:

1. If you use EC2 IAM profiles you don't need the Access keys or secret keys in the Magento config.

2. If you don't use the Nginx ngx_aws_auth module, you need to allow public access to the S3 bucket so that nginx can proxy images without getting a 403 forbidden. You can set a bucket policy like this (make sure you uncheck block all public access first:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPublicGetObjectOnly",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::BUCKET/*"
        }
    ]
}

This will ensure nginx can still proxy but nobody can just browse to the bucket to see the assets. I've not tried the ngx_aws_auth module but I believe if that module is used and it's configured with the keys, you don't need to set public access above.

Alternatively, there's methods of locking down access to the S3 bucket via VPC. So if you're using EC2 to host Magento, you could add an additional layer of security by just allowing resources in that VPC access to the bucket. Again, it depends on what security you need.

3. The Nginx code snippet for proxying should be rewritten as follows to use new virtual hosted style access instead of path style access (which is being deprecated, see more information here)

location ~* \.(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ {
    # Proxying to AWS S3 storage.
    resolver 8.8.8.8;
    set $bucket "<s3-bucket-name>";
    set $region "<s3-bucket-region>";
    proxy_pass https://$bucket.s3.$region.amazonaws.com$uri;
    proxy_pass_request_body off;
    proxy_pass_request_headers off;
    proxy_intercept_errors on;
    proxy_hide_header "x-amz-id-2";
    proxy_hide_header "x-amz-request-id";
    proxy_hide_header "x-amz-storage-class";
    proxy_hide_header "Set-Cookie";
    proxy_ignore_headers "Set-Cookie";
}

[hguthrie]

@tdm4 Thanks for adding ideas to the issue!

[tdm4]

One thing I did notice is.. the new media gallery doesn't work when S3 is used as remote media. I've run the media.gallery.synchronization and media.content.synchronization commands but there's no change. The old media gallery still works though.

[hguthrie]

This issue appears to still be valid but was not migrated to the new repository. I grabbed the information from this issue and placed it in https://github.com/AdobeDocs/commerce-operations.en/issues

You are welcome to correct, clarify, or add to this issue in the new repository: https://github.com/AdobeDocs/commerce-operations.en/issues/116