- Le plus récent
- Le plus de votes
- La plupart des commentaires
Is is possible to utilize S3 Gateway Endpoint in centralized Network Account with AWS Network Firewall?
No. Gateway Endpoints are only accessible from the VPC in which they are hosted.
In the environment that you have described you must either use Interface Endpoints in the central network account; or run a proxy fleet in the central network account for S3 access to the Gateway Endpoint (because then traffic will appear to come from the proxy fleet rather than the source VPC).
Note that you have the ability to control what is access through the endpoint(s) using endpoint policies so that's a good way to control access. With many accounts and distributed Gateway Endpoints I'd suggest that automation is your friend here.
Traffic to S3 is going to be encrypted (well, at least 99.99% of it). Inspecting that requires you to break TLS (something I'm not in favour of) - and doing that requires that some client libraries have certificate checking disabled which may or may not be possible depending on the application using that library. Disabling certificate checking means that the encryption can no longer be trusted - so be careful there.
Keeping S3 Gateway endpoint in all "spoke accounts" is no option because we would have no clue what data is leaving our AWS environment towards S3 bucket (from potentially anyone in Public Internet)
A user on the public internet can't use a Gateway Endpoint to reach a S3 bucket. I think this needs some clarification because you say "leaving our environment towards S3" (which is what I would expect - in addition to sending data to S3); but "from potentially anyone in public internet" doesn't compute in this sense.
Contenus pertinents
- Réponse acceptéedemandé il y a un an
- demandé il y a 10 mois
- demandé il y a un an
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
First of all, thanks for this comprehensive response! ** Reg. "proxy fleet in the central network account for S3 access to the Gateway Endpoint": I was assuming that MAYBE the AWS Network Firewall (NFW) would act as such a proxy. But it will not work after some investigation. (my idea was: A PHZ in central Network account points S3-requests from "Spoke Accounts" towards AWS NFW in central Network Account. The NFW itself is deployed in a subnet with a Route Table entry towards S3 Gateway Endpoint. But this will not work. It will at least fail because resolver rules logic is as follows acc. to my investigation: a) Forward Rules, b) Private DNS / PHZ, c) VPC DNS (incl. S3 Prefix List), d) Public DNS) ** Reg. "no clue what data is leaving our AWS environment towards S3 bucket (from potentially anyone in Public Internet)" - What I was trying to say is: the source is in our AWS environment, the target can be an S3 bucket from our AWS environment, or an S3 bucket from a "hacker" AWS environment. But in the end you answered it already: Restricting access trough VPC endpoint policies would be the way to go here. ** Any idea on how the VPC endpoint policies can be governed from a central location?
Main purpose of the Network account was to have one place where the Network team can configure all Network items. Moving S3 endpoints to the "Spoke Accounts" means the Network team must ensure the endpoint policies are all set correctly.
Yes, it's a common challenge in distributed environments where centralized teams (networking, security, etc.) have challenges dealing with resources in other accounts. My best advice here is to have those teams embrace automation and use appropriately scoped cross-account roles to perform those tasks. While there is definitely some ramp-up in terms of knowledge (and time) the benefits going forward (especially in AWS where automation is encouraged) are huge. And this is coming from and 'old-skool' network engineer...
Thanks for sharing your advice!