AdobeDocs/commerce-operations.en

Request for a new topic: Expand remote storage authorization example

Aperta

#116 aperta il 21 dic 2023

 (0 commenti) (0 reazioni) (0 assegnatari)HTML (60 fork)auto 404
help wanted

Metriche repository

Star
 (10 stelle)
Metriche merge PR
 (Metriche PR in attesa)

Descrizione

Description

Migrated from original Issue in DevDocs: https://github.com/magento/devdocs/issues/8823

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.

Content checklist

  • The topic provides an explanation of how ____ works.
  • The topic provides steps for ____.
  • The topic contains code samples that shows ____.

Additional information

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

Suggestions

The following suggestions were provided in the original Issue.

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

  • 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.

  • 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";
    }
    

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.

Guida contributor