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
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.
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)
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.
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?
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.
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.
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.
[0]: https://hackertimes.com/item?id=15084728