Zero Trust access to apps hosted on Google Cloud
Step Ahead secures access to web-based apps such as App Engine, Compute Engine, and Google Kubernetes Engine hosted on Google Cloud. The App Engine is deployed as a standard or flexible environment application secured with Identity-Aware Proxy (IAP). The IAP allows the user to establish a central authorization layer for applications accessed by HTTPS. This will allow your organization to use an application-level access control model instead of relying on network-level firewalls.
IAP policies scale across an organization. Step Ahead works with customers to define access policies centrally and apply them to all of the customer applications and resources. Step Ahead helps their customers identify and build a dedicated team to create and enforce policies and enable customers to protect their applications in the cloud or on premise.
How IAP Works?
Identity-Aware Proxy (IAP) uses JSON Web Tokens (JWT) to make sure that a request to the app is authorized. This protects the app from the following risks:
● Accidentally disabling IAP
● Misconfigured firewalls
● Access from within the project.
In order to secure the application, it is necessary to use signed headers for all application types. Group-based application access to restrict access to certain groups. For example, a resource could be accessible for employees and inaccessible for contractors, or only accessible to a specific department.
When an application or resource is protected by IAP, it can only be accessed through the proxy by users who have the correct Identity and Access Management (IAM) role. When access to an application or resource by IAP is granted, the user is subject to the fine-grain access controls of the product without requiring a VPN. When a user tries to access an IAP-secured resource, IAP performs authentication and authorization checks. The exhibit below defines the process flow of IAP.
Requests to the Google Cloud resources come through App Engine or Cloud Load Balancing (HTTPS). The infrastructure code for these products checks to verify if IAP is enabled for the app or backend service. If IAP is enabled, information about the protected resource is sent to the IAP authentication server. This includes information like the Google Cloud project number, the request URL, and any IAP credentials in the request headers or cookies.
Next, IAP checks the user’s browser credentials. If none exist, the user is redirected to an OAuth 2.0 Google Account sign-in flow that stores a token in a browser cookie for future sign-ins.
If the request credentials are valid, the authentication server uses those credentials to get the user’s identity. The authentication server then uses the identity to check the user’s IAM role and check if the user is authorized to access the resource.
After authentication, IAP applies the relevant IAM policy to check if the user is authorized to access the requested resource. If the user has the IAP-secured Web App User role on the Cloud Console project where the resource exists, they’re authorized to access the application.
When you turn on IAP for a resource, it automatically creates an OAuth 2.0 client ID and secret. If you delete the automatically generated OAuth 2.0 credentials, IAP won’t function correctly.
IAP secures authentication and authorization of all requests to App Engine or Cloud Load Balancing HTTP(S). IAP doesn’t protect against activity within a project, such as another VM inside the project. In order to overcome this limitation, Step Ahead uses synchronized security solutions to configure our intelligent Sophos XG Firewall and load balancers to protect against traffic that does not come through the serving infrastructure.
Source References:
Google Zero Trust IAP