Conversation

Notices

Embed this notice
mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:37 JST mcc

I can't figure out how to use Amazon AWS. I am trying to set up the simplest possible thing (https-protected access to a s3 bucket) and failing. Can anyone give me advice :( https://cohost.org/mcc/post/1453305-please-help-i-am-baby
In conversation Thursday, 11-May-2023 08:00:37 JST from mastodon.social permalink
Attachments
1. Domain not in remote thumbnail source whitelist: staging.cohostcdn.org
  
  Please help I am baby and do not understand Amazon S3
  
  from https://cohost.org/mcc
  
  https://mastodon.social/@mcc/110278058804094562 [https://mastodon.social/@mcc/110278058804094562] Everything is so broken I can't even get the post embed explaining how broken things are to work. I have this site, dryad.technology. It's my "static content" site. It has always been HTTP-only, no TLS. For reasons, I have to fix that now. It has to go HTTPS. When I set this site up 7 years ago I decided I would finally use ~cloud technology~ (I self-host my other sites and was tired of it). The architecture is: * Content hosted in a secret S3 bucket * Cloudflare caches/proxies the S3 bucket and serves at the domain. I pay almost nothing because Cloudflare is free, and Amazon charges me only for the traffic between Amazon and Cloudflare, which comes out to sub-penny levels. But I can't figure out how to move this setup to HTTPS. I tripped over this 7 years ago and I'm tripping over it now. Can anyone help. Me. With this. Here is a list of things I tried that don't work. Imagine my secret S3 bucket is named BEEFCAFE. 1. Serve site from http://BEEFCAFE.s3-website-datacentername-1.amazonaws.com/ Cloudflare proxies, https-encodes, adds a Cloudflare-signed https certificate Why this doesn't work: This is fake https. It's HTTPS signed from Cloudflare to the user, but it passes unencrypted over the open Internet between Amazon and Cloudflare. This is lying. It is giving a false sense of security to my users. I won't do it. The domain above does not respond to requests on port 443. 2. Serve site from https://s3.amazonaws.com/BEEFCAFE/index.html Cloudflare designates site DNS as s3.amazonaws.com, and adds a rewrite rule that tacks on BEEFCAFE/ to all inner-website requests. Why this doesn't work: Although I can go to https://s3.amazonaws.com/BEEFCAFE/index.html in a web browser and see my site URL, they appear to be specifically denylisting Cloudflare. When accessing dryad.technology/BEEFCAFE/index.html after making the change I get: AccessDenied Access Denied R7QMB7JF9RKMTJ12 CCQMYXOnUVx1OTNPYl0W/GYL/xHLBm2kZyXq2aBls4YFiHSvNgUTRJfKD9J/znX05MkmYbngAc0= … or similar nonsense, on every pageload. I cannot find any Amazon documentation explaining why requests from CloudFlare specifically would result in this AccessDenied request. However there is a stack overflow answer [https://stackoverflow.com/a/39769368/6582253] that purports to address this exact problem, for this exact scenario, by setting a JSON "bucket policy". Following this page's had literally no effect. It did not change the error when accessed through CloudFlare nor did it block me from accessing through non-cloudflare. That is weird enough I wonder if I did something wrong 3. Follow the instructions There is a CloudFlare support page [https://developers.cloudflare.com/support/third-party-software/others/configuring-an-amazon-web-services-static-site-to-use-cloudflare/] which purports to explain how to do exactly the thing I want to do [use CloudFlare to serve pages stored in an S3 bucket]. The page is a bit oblique. It explains you need to go into the bucket policy editor and then "use this sample to fill out the needed JSON code". The referent of "this sample" is not in any way indicated, it is as if a sentence is missing. However I think they mean the IP based bucket policy [https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-IP]. The CloudFlare support page then directs you to fill in the list of known CloudFlare IP ranges. This produces a JSON very similar to the one from the stackoverflow page listed above. I'm not sure whether this support page gives me what I want. For one thing, it has a step directing me to "redirect requests from this bucket’s URL to the subdomain bucket URL you created". This suggests I'm going through my BEEFCAFE.s3-website-datacentername-1.amazonaws.com domain from approach 1 above, which implies I'll founder on the same http/https problem as before. However they also make oblique reference to an "endpoint", and there is an "access points" menu in Amazon's interface I have not fully explored. So maybe this will solve one of my problems (it is theoretically possible someone could guess my bucket name and access it directly instead of going through dryad.technology, mostly harmless but still worth avoiding) and I can solve the https problem in a following step. Why this doesn't work: The Amazon examples page contains an interesting statement: "Warning: Before using this policy, replace the 192.0.2.0/24 IP address range in this example with an appropriate value for your use case. Otherwise, you will lose the ability to access your bucket." Editing the JSON, I think: Wait, does that mean I won't be able to read the bucket, or does it mean I won't be able to administrate it? Hopefully it's just reading the bucket! No, it was total. After applying the change, my S3 bucket was suddenly only accessible from CloudFlare IPs. Meaning the site still loaded (because it was loaded from a CloudFlare site) but all of the AWS administration pages for the bucket now showed big red error messages, and I assume I tried to edit it that wouldn't work either. Hilariously this meant I was also blocked from undoing the configuration change I had just made. (Fortunately Amazon foresaw someone might make this mistake, and if I logged in from my superuser account it unlocked the bucket policy JSON form only, allowing me to reverse the change. 4. CloudFront? Amazon's help pages do contain a page on how to serve S3 as HTTPS. What they recommend is using a different Amazon service called CloudFront [https://repost.aws/knowledge-center/cloudfront-https-requests-s3]. Not CloudFlare. CloudFront. So in this model S3 funnels to CloudFront which funnels to CloudFlare which funnels to the user. The problem here is that CloudFront is not a straightforward web endpoint but a full-featured CDN, which isn't exactly what I want. This would mean two layers of caching which would be odd and could even be glitchy; it also implies I'll be getting charged twice per page update, which could potentially increase my AWS costs from one-quarter of a cent per year to as high as one-half of a cent per year. Given that this very almost works— I can access AWS via http, and I can access it (at the s3 site) via https as long as I don't do so via CloudFlare— without CloudFront, I'd prefer not to jump into that particular pool of frigid water unless I'm assured by someone who has done this before that it really is the only way. A second problem is that it's not clear to me from these docs how CloudFront accesses S3. Is it http? Is it https? Is it… whatever Amazon-internal communication method "aws://" is, which I assume but have not specifically seen documented is confirmed secure? My "win condition" is that I have an S3 bucket, access to which is unrestricted with appropriate AWS credentials, and access to which is possible via public HTTPS but only when accessed by CloudFlare. Data should be encrypted (to ensure integrity) via some key or other at each link between the S3 bucket and the user's browser. I don't pay for CloudFlare and the S3 charges for updating pages and transmitting them to the CloudFlare cache comes out to a few pennies per decade, so I'm basically hosting high-availability static content for free. Can I make this work? Is there something I need to be reading? I am flailing.
- Embed this notice
  feld (feld@bikeshed.party)'s status on Thursday, 11-May-2023 08:00:33 JST feld
  in reply to
  - Kevin Boyd (he/him) 🇨🇦
  one of the most expensive things you can do is serve content from S3 and *not* cache it with CloudFront
  
  In conversation Thursday, 11-May-2023 08:00:33 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:34 JST mcc
  in reply to
  - Kevin Boyd (he/him) 🇨🇦
  @kboyd My CloudFront has caching fully disabled because I have an actual WAF in front
  
  In conversation Thursday, 11-May-2023 08:00:34 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:35 JST mcc
  in reply to
  
  This appears to be the actual, recommended solution https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html
  So they want me to use either "Cloudfront Functions" or "Lambda" to do a special redirect rule to add index.html. Except! The redirect rule would be solely name-based. I can't tell it "index.html if it's a directory". It *guesses* it's a directory based on the lack of file extensions. So if I take this approach I will never again serve a file which does not have an extension from this domain.
  What. The. Actual, Fuck.
  In conversation Thursday, 11-May-2023 08:00:35 JST permalink
  Attachments
  1. Untitled attachment
- Embed this notice
  Kevin Boyd (he/him) 🇨🇦 (kboyd@phpc.social)'s status on Thursday, 11-May-2023 08:00:35 JST Kevin Boyd (he/him) 🇨🇦
  in reply to
  
  @mcc Even when it's mostly working, it's still super annoying. Heavy caching means that content takes ages to update, and if you have an emergency need to update it you have to make custom cache invalidation calls. (At least this was my early experience & why I've avoided it ever since.)
  
  In conversation Thursday, 11-May-2023 08:00:35 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:36 JST mcc
  in reply to
  
  "The timeouts… can be from an hour to over 24 hours"
  
  In conversation Thursday, 11-May-2023 08:00:36 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:36 JST mcc
  in reply to
  
  Okay I've got it working but apparently *it is not possible, when cloudfront is in front of S3, to automatically serve the file "index.html" when accessing a directory*. No no URL on my site actually works. Every source I am finding recommends fixing this by turning off s3 access from cloudfront and using having cloudfront access s3 via web, which means there will be an unencrypted link between cloudfront and s3.
  How
  How is this a real commercial product
  
  In conversation Thursday, 11-May-2023 08:00:36 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:36 JST mcc
  in reply to
  
  I'm just a girl, standing in front of the fifth largest company in the world, asking your web hosting product to offer the same level of functionality that Geocities had in 1994
  
  In conversation Thursday, 11-May-2023 08:00:36 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:00:37 JST mcc
  in reply to
  
  Update: Wow, I uh… I feel like I've been waiting on this exact problem for a pretty long time. https://www.reddit.com/r/aws/comments/1180g8f/cloudfront_distribution_is_stuck_in_deploying/
  This is supposed to be the global leader in its product class, right
  In conversation Thursday, 11-May-2023 08:00:37 JST permalink
  Attachments
  1. Untitled attachment
- Embed this notice
  feld (feld@bikeshed.party)'s status on Thursday, 11-May-2023 08:01:39 JST feld
  in reply to
  - Kevin Boyd (he/him) 🇨🇦
  oh that's good then
  
  In conversation Thursday, 11-May-2023 08:01:39 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:01:40 JST mcc
  in reply to
  - feld
  - Kevin Boyd (he/him) 🇨🇦
  @feld @kboyd I am caching it elsewhere.
  
  In conversation Thursday, 11-May-2023 08:01:40 JST permalink
- Embed this notice
  mcc (mcc@mastodon.social)'s status on Thursday, 11-May-2023 08:24:02 JST mcc
  in reply to
  - feld
  @feld Cloudflare is very cheap!
  
  In conversation Thursday, 11-May-2023 08:24:02 JST permalink
- Embed this notice
  feld (feld@bikeshed.party)'s status on Thursday, 11-May-2023 08:24:02 JST feld
  in reply to
  
  I work with the guy who is literally the world expert in Amazon billing (he has amazing tools that Amazon never exposed to customers) and he has put the fear of god into me over public S3 buckets being hit directly, so I wanted to warn you but you're on top of it 👏👏🙇♂️
  
  In conversation Thursday, 11-May-2023 08:24:02 JST permalink

Public

Conversation

Notices

Feeds