Introducing App Engine Firewall | Hacker News Reader

Introducing App Engine Firewall

cloudplatform.googleblog.com

114 pointsartsandsci33 comments

This seems almost perfectly in response to the HN submission on the NYT Games migration to Google Cloud[0], who listed App Engine's lack of a firewall as one of their complaints with the service

[0]: https://news.ycombinator.com/item?id=15084728

It's quite the coincidence but we're very excited about it :)

- NYT Games Team

Love it! I was thinking of migrating off GAE for this reason, but now will re-evaluate.

One feature request - can we add a URL parameter to the firewall rule? The idea is I want to restrict access to certain URLs to a well-known set of IPs - e.g. I don't want login into admin pages unless coming from a known IP. Is this possible on GAE right now?

I know I can split the service into two (restricted and public) and then firewall the restricted service, but wondering if there's a simple way to parametrize firewall services by URL.

I too would love this. For now, we have add an auth layer to manage this and would love for that to not be necessary.

We agree that this is an important use case, and is something we considered during the design. It is now supported by placing a Web Application Firewall in front of the App Engine application. We chose to limit the initial set of firewall features to IP address range blocking only — in part because that's sufficient to enable a WAF to front an App Engine Application.

-Tad Hunt (Manager on the App Engine team that brought you this firewall)

Got it - thanks. Any plans to add this as an integrated feature so we don't have to set up a separate WAF?

Feel free to reach out, my email is in my profile. We can discuss what you're looking for.

Would love to - couldn't find your email in your profile tho.

To keep the UI simple, I'd like to specify a URL and specify the IP range(s) that are allowed to access each. Bonus points if I can in addition to web UI submit and change the map programmatically. The first allows for greater security for admin pages and similar internal uses. The second allows us to provision for our enterprise users dynamically, who are at well known IPs.

My heart skipped a beat when I read the title as App Engine Farewell. Have been actively using App Engine since 2009 and the love it gets has been on a long downslide. Happy to see this feature come out though, the previous lightweight dos.yaml method was quite lacking.

You were always able to black list IP addresses using dos.yaml (https://cloud.google.com/appengine/docs/standard/python/conf...). This seems to be taking that one step further.

I think this is a good product offering, and it's nice to see them compete with AWS on another front, as well as Digital Oceans' offering.

However, I wonder if these abstractions are detrimental to developers understanding the underlying technology? I'm not a supremely experienced developer but it takes very little effort to understand, for example, ufw and iptables on Linux distros.

Personally, though I'm (mostly) front end, I spend the majority of my time on the command line. My main editor is vim, I write bash scripts to do what I need instead of manually performing tasks, I often just use `cat` to write files instead of opening my editor, etc.

I found that managing things from the command line such as firewalls, daemons, and other tasks like managing databases, gave me deeper comprehension of what's going on. Are abstractions like this becoming crutches for tomorrows' developers?

I think you are right with the understanding, but its a trade-off to be able to build bigger things more quickly and easily.

iptables on the face is easy to use. But at scale becomes difficult to use.

Also iptables does much more than just firewalls and can become a confusing tool.

Also, in a large enterprise organization the firewall guy is different than the software engineering team which is different than architect.

I like things like this not because they make the underlying tooling more opaque/encapsulated, but because they expose that tooling to network-API-based management, through tools like AWS's CloudFormation et al.

To be able to set up firewall rules for my app in concert with installing the app—and to roll out changes to those rules as part of rolling app updates—my cloud orchestration system has to be told that a given box "is" a firewall, or discover that fact through SNMP or WSDL probing. If it has that capability, then it may as well let me assign properties to the "box-as-firewall" object in its convergence model, rather than the "box-as-box" object—and then, given that it's not doing anything other than being a firewall, maybe let me leave the "box-as-box" object unspecified and have it created automatically by requirement of the "box-as-firewall" spec.

Now we're back to the "opaque appliance" abstraction (at least by default), without ever having chosen to design things that way.

While they look the same, the technologies serve different purposes.

iptables/ufw block requests at the VM level. So traffic flows all the way to your VM and then your VM spends CPU cycles rejecting those packets.

In contrast, these firewall technologies can block traffic at the network edge of the cloud provider. This is done by propagating rules to the edge routers.

Ahh, that changes my perspective on this. That suddenly seems vastly more useful than it did, to me.

Cool, now give me PHP 7.1

And Python3 with the NDB library.

Oh yeah that too

+ websockets

Why do they return HTTP 403 instead of dropping the traffic or returning an ICMP message?

This is a good feature. Wish app engine provides capability for blue-green deployments.

What do you mean? App Engine supports many versions of your application running simultaneously. You just deploy to a new version and migrate traffic (slowly or quickly, your choice).

For those looking for a more automated approach for doing things like blue/green, take a look at Spinnaker (http://spinnaker.io). Here's a quick video for App Engine - https://youtu.be/pOPgTHz_nYw

Disclaimer, I work on the project.

We don't have a deployment strategy named "blue/green" for the App Engine provider for various reasons, but do provide stages such as "deploy", "disable", "enable", "destroy", as well as setting traffic split percentages that you can string together in a pipeline.

Edit: okay, no markdown on HN

Does this work with the flexible environment too?

Yep https://cloud.google.com/appengine/docs/flexible/python/appl...

Does AWS offer something similar?

They have offered a more featureful product for a while: https://aws.amazon.com/waf/

That being said, the simplicity of this product is elegant and solves a lot of use cases without a lot of headache.

Azure too

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_S...

Yes, AWS has security groups.

This is a great first step. Reminds me of when Microsoft started shipping Windows with a firewall with XP.

haha ! It come at a better timing than this. Yesterday we had a huge discussion around that in HN !!

Reply on news.ycombinator.com