Crucial error n S3 instructions

At https://support.cloudflare.com/hc/en-us/articles/360037983412-Configuring-an-Amazon-Web-Services-static-site-to-use-Cloudflare you have a small but crucial error, in the condition block of the bucket policy you have ‘IpAddress’ instead of ‘NotIpAddress’. As it is the bucket policy will block all of Cloudflare and provide access to everyone else.

@kody is one of the super-fixer-uppers of Support Docs.

Aww, appreciate the attention. Updated the condition block and then applied similar example instructions to the Restoring IP addresses article.

1 Like

I think whatever update happened here (or perhaps something afterward) actually has exacerbated this problem or created it. Here’s what I see on the linked doc as of today:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.example.com/*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "192.2.0.1" (example IP address),
                        "192.2.0.2" (example IP address),
                        (add all IPs listed at https://www.cloudflare.com/ips)
                    ]
                }
            }
        }
    ]
}

This says: “If the incoming IP address is not from Cloudflare, then allow the request to read from the S3 bucket.”

That doesn’t seem to make sense to me; it seems to be the opposite of the desired behavior. And in fact seems to cause the exact problem that OP mentioned. (Maybe OP was mistaken about the details, or maybe the doc has otherwise changed since they posted; I’m not sure.)

For contrast, here’s an older version of the doc that has a rule which makes more sense to me: [I’m apparently not allowed to post links as a new user, but you can find it in the Internet Archive’s Wayback Machine for September 2021]

Either of the following combos would seem sensible in this case:

  • "Effect": "Allow" + IpAddress: [all of Cloudflare’s IP addresses] (i.e. explicitly allow access to Cloudflare IPs)
  • "Effect": "Deny" + NotIpAddress: [all of Cloudflare’s IP addresses] (i.e. explicitly deny access to everything except for Cloudflare’s IPs)

^Not sure if these are equivalent or if they differ in behavior depending on the user’s other S3 settings. I’ll let the Cloudflare team or other folks with AWS experience investigate that.

Just thought I’d share that the current example as pasted above seems wrong; I hope this helps someone who comes across it. There are a few other threads (e.g. Bucket Policy for IP Restrictions Not Working - #4 by matt.edwards597) on this same document, and they’re unfortunately tricky to reconcile because the document seems to have gone through several dramatic iterations over the last couple of years.

Any update on this? I decided to read the policy and I agree with anonymous3’s assessment here. See the policy listing in Mike’s 4 year old article: https://miketabor.com/how-to-host-a-static-website-using-aws-s3-and-cloudflare/

It uses Allow with IpAddress.

Also, After you save the static website hosting configuration, you can skip disabling public access for your bucket. is also apparently incorrect, since you have to enable public access in order to edit the policy json.