magento / devdocs

[Deprecated] Magento Developer Documentation
Open Software License 3.0
673 stars 1.77k forks source link

Expand remote storage authentication example #8823

Closed hguthrie closed 9 months ago

hguthrie commented 3 years ago

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] commented 3 years ago

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


tdm4 commented 2 years ago

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.

  1. 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 commented 2 years ago

@tdm4 Thanks for adding ideas to the issue!

tdm4 commented 2 years ago

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 commented 9 months ago

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