Securing App Engine Applications

App Engine is Google’s oldest Platform As A Service(PaaS) offering. App Engine allows application teams and developers alike to focus on developing the core component of an application (“the code”), and Google Cloud (“the platform”) will manage the infrastructure for you by scaling resources up and down. In addition, App Engine is natively a publicly accessible service meaning your application is on the World Wide Web for anyone to see.

This article will review the security controls available to administrators within Google Cloud Platform, specific to App Engine. App Engine offers the following security controls natively:

• Secure web access via HTTPS Request
• Access control via Identity and Access Management(IAM)
• App Engine Firewall
• Ingress Controls

In addition, you can leverage services like Identity-Aware-Proxy (IAP) for enhanced protection of your applications. App Engine comes in two flavors, Standard or Flexible, but the security guardrails that we discuss in this article apply to both.

HTTPS

By default, all applications receive an HTTPS certificate applied to the primary URL of the App Engine application. This means your web application will be serving secure encrypted web traffic from the start by redirecting HTTP traffic to the HTTPS encrypted version of the application. Additionally, App Engine offers administrators two options for hosting web applications; you can leverage the default domain (*.appspot.com) or apply a custom domain to your application.

If you decide to leverage the default domain, the URL format for the application will look similar to this https://PROJECT_ID.REGION_ID.r.appspot.com. The project ID is the name of the GCP project that App Engine has been deployed to, and the region ID represents the region where your application is hosted. Alternatively, administrators can leverage a custom domain with a Google-managed SSL certificate or a self-managed SSL certificate. This allows administrators to choose a naming convention and keep the hosting information of the application private. With HTTPS enabled on a Cloud Load Balancer, administrators can define SSL Policies with specific features negotiated with clients accessing the application. Security is built into each step of the application deployment process in App Engine.

Access Control

App Engine access control determines who or what has permission to access services and resources within a given application using Identity and Access Management (IAM). This allows administrators to put access control mechanisms to grant different teams access to an application or grant other Google Cloud services access to an application. In the case of granting teams access to applications hosted in App Engine, you can delegate the App Engine Admin or App Engine Creator IAM role to allow members of the team to create specific application resources.

When provisioning access to other Google Cloud services, the recommended approach is to leverage a service account. App Engine offers two service account options:

• App Engine default service account - This account is automatically created for you when you set up an App Engine instance in your GCP project. It is the default identity that is applied to all versions of an App Engine application.
• User-managed service account - This account is manually created leveraging IAM. You specify what versions of your application will leverage this account instead of applying it to everything.

By default, the App Engine default service account establishes connections to other GCP services running in the same project. This service account is created by Google and granted full permissions to all services that share the same GCP project as the App Engine deployment.

From a secure application perspective, having this much power given to the default service account all the time may become a recipe for trouble in the future. Therefore, as a best practice, creating a user-managed service account and scoping the permissions down using custom or predefined IAM roles to only what is required for the application to function properly. One caveat to note with this approach is that user-managed service accounts for App Engine are still in preview on the platform, and Pre-GA offering terms apply.

App Engine Firewall

GCP provides the ability to specify both Ingress and Egress firewall rules that control network traffic entering a VPC. However, because App Engine is one of the oldest services on GCP, it has an independent firewall engine that controls:

• Web traffic destined for *.appspot.com or custom domains
• Traffic coming from Cloud Load Balancing
• Traffic coming from other services such as Google Compute Engine or Cloud Tasks

App Engine firewall rules only control the flow of Ingress traffic, and all Egress traffic is allowed by default. By default, App Engine allows all incoming traffic as part of the default ruleset. Suppose you want to prevent all incoming traffic from hitting your application. In that case, it is best to change the default rule to deny and specify what IP addresses or ranges are authorized to talk to your application.

The App Engine firewall also allows administrators to set special configurations for certain Google Cloud services that need to Ingress into App Engine. For example, if Cloud load balancing is in front of your application, then the firewall rules will not be evaluated till the traffic is sent from the load balancer to App Engine. Therefore, to better control traffic flow into App Engine, administrators can use Ingress controls.

Ingress Controls

Ingress controls allow administrators to be more opinionated with the network flow of HTTPS requests to App Engine applications. For example, restrictions can be placed on the incoming traffic destined for the application, such that traffic can only be accepted from an internal VPC or on-prem network or a Cloud Load balancer. When this restriction is implemented, all other traffic is denied from reaching the application. Ingress controls support three different types of HTTP/S traffic patterns:

• ALL - Allows all traffic from anywhere to access App Engine applications
• Internal and Cloud Load Balancing - Allows traffic from Cloud Load Balancing or the VPC traffic with Private Google Access enabled. All other requests will be denied with a 403 error
• Internal-Only - Allows traffic from the VPC network with Private Google Access enabled within the same project that is hosting App Engine.

Ingress controls supplement the configurations that you apply in your App Engine firewall rules with an all-or-nothing approach. The traffic restrictions apply to all incoming traffic and cannot be segmented to specific source networks like a standard firewall rule. These controls can be used to harden applications further and provide an added layer of security.

Identity-Aware Proxy (IAP)

Finally, Identity-Aware Proxy (IAP) allows administrators to access an application or VM resource by verifying the user’s identity, IP address, and end-user device attributes for determining allowed access. IAP is a great building block towards zero trust access control as it does not rely on a user’s network. Instead, IIAP intercepts the web request sent to an App Engine application, authenticates the user making the request via Google’s Identity service, and only allows the user’s request if the user is an authorized user.

IAP allows App Engine administrators to establish a centralized authorization layer for applications accessed by HTTPS to use application-level access control instead of network-level access control. The access policies can be defined centrally and applied to all services within an App Engine application or specific services that need to be secured. In addition, IAP integrates with a wide range of external identity providers and can be leveraged with protocols providers such as:

• OAuth (Google, Microsoft, Twitter, Facebook, etc.)
• SAML
• OIDC
• Custom
• Anonymous

At a high level, IAP provides two main layers of protection for your application:

• Resource Authorization - OAuth2 flow for generating the signed access token. IAP takes this token and validates the user’s identity
• App Validation - IAP uses signed headers to verify a user’s identity. This helps provide an added layer of protection if users manage to bypass IAP.

In summary, App Engine is a great way to implement microservices in GCP, given that Google Cloud handles all the management of the infrastructure for you. Securing microservice architectures in App Engine can be easy or complex, depending on the requirements. Google Cloud gives administrators great options for securing the application or specific components of the application.