How to get Cloud Identity-Aware Proxy up and running

You need tools to secure your applications that are aware of people and devices. You wouldn’t let a passenger on a plane without first inspecting who they are and what they’re carrying, and you should treat your applications the same way. This context-aware way of thinking drove Google’s adoption of BeyondCorp, and has been gaining traction.

Modern applications rely on a large set of systems: web servers, microservices, and scalable, serverless deployments. You want all the subcomponents accessible to each other, and your employees, but if you’re not careful you could open them up to absolutely everyone on the internet. Nobody wants that.

Episode 3

Complex access policies

EatAnd.Run, a startup catering to avid joggers with snack cravings on the go, saw their systems expanding rapidly as they scaled up, and needed to secure the large amount of Personally Identifiable Information they were storing about their runners, joggers and power walkers, including location data over time and personal contact lists. They knew they had to be more careful about which employees and contractors could access which systems, so they examined their options.

The naive solution would be to exhaustively list which people or services do or don’t have access to each service they run. Sadly this gets complex, very quickly, and creates a maintenance nightmare. The time and energy required to enumerate every connection would have slowed them too much.

Their first approach, as they were just starting out, had no model at all: everything can talk to everything else. This helped with accelerating growth, but became too permissive a stance for the security team to tolerate.

Fully open access leads to compromise or exfiltration

Next they moved to a more finely grained access model: the EatAnd.Run team tracked which services could talk to which, so their customer database could talk to their marketing management system, the finance operations tools were restricted from being accessed from outside the corporate network, and customer case management could access the registered user database, etc. etc. etc. They wrote out firewall rules one by one to address these use cases–painful but effective.

This also became infeasible, as the policies quickly became intricate or even unfathomable for anyone at EatAnd.Run to even understand. At that point, nobody at the company could understand how it was supposed to work or what the possible outcomes would be.

Time to simplify

With Identity-Aware Proxy (IAP) and Identity and Access Management (IAM) the EatAnd.Run DevSecOps team created clear, readable, logical policies to control which people get to see which applications and when. They also went a step further to take advantage of different kinds of conditions to customize criteria for access. And they found it easy to evolve and change as the team kept growing, adding new employee groups and new applications with just a few clicks.

Contrast this with the alternative: complex firewall policies, VPN restrictions, and access controls. A new cottage industry sprang up in the 90s just to help simplify these rules and reduce complexity and redundancy as the number of rules exploded into the 10s of thousands.

Mmmm, spaghetti

With IAP the EatAnd.Run team can quickly pick which app, which people, and which access roles. Above you can see how they’ve set up two app Owners, who can fully manage the App Engine app, and one of the employees, Talky McTalkerson, as the IAP policy admin to maintain policy as we hire more employees.

Taking it further

The App Engine and GKE quickstarts covered previously helped EatAnd.Run get IAP up and running quickly; next the team wanted to extend their model with Cloud IAM Conditions and establish more nuanced access policies. Some of the applications already moved to Google Cloud contain sensitive data, or works in progress that they want to protect from potential leaks.

EatAnd.Run are preparing to launch a new social sharing component to their app, but it’s not fleshed out enough yet to handle their full user-base. So they set up the new version on App Engine behind IAP, and restrict it to just the Engineering team for dogfooding.

Opening up IAP in Cloud Console, they first removed the employees group from the IAP-Secured Web App User role for the App Engine App, because they now want to make permissions different for different versions.

They decided that it’s safe for everyone to see version 2, but only want engineering to see version 3, the newest and least stable build.

Augmenting IAP with conditions

They’ve already got a new version of the app behind IAP and restricted to full-time employees, but now they want to go further.

Right now only the Engineering team can now use the new version and its features, as they are still testing them out. Good start, but there’s still the risk of leaks. To go a step further, the team used Access Context Manager to create more conditions for access beyond just group membership. Because the team already set up Endpoint Verification on their devices, they are getting inventory data on the state of everyone’s machines.

To make sure only secure devices accessed this new version, they decide to limit access to devices that conform to their security policies. They must be running up-to-date Chrome OS, so they are protected from local or browser-based malware. They need a screen lock, so an absent-minded employee at the coffee shop won’t leak secrets when they step away for a mocha. And they require disk encryption, so a stolen device will yield no secrets to a local drive interrogation.

“No, not brute force, I’ll tell you anything you want!”

These constraints help the team keep their food-finding innovations private, and avoid compromise by snooping cameras or malware. They make a new access level in the Access Context Manager console to enforce this access, so only devices that meet these conditions will be allowed to access the new version of their app.

Now the app is secured with person and device conditions

In the Cloud Console, they can set this up under Security, in Access Context Manager.

And then it’ll show up in the list of access levels like so:

It’s also simple to do this via gcloud, by making a new conditions.yaml file (you can use any name you like) with the constraints:

- devicePolicy:
     osConstraints:
       - osType: DESKTOP_CHROME_OS
       minimumVersion: 70.0.3538
     requireScreelock: true
     allowedEncryptionStatuses: ENCRYPTED

After saving, you can create the new access level on the command line:

gcloud beta access-context-manager levels create Supper \
   — title SupperGuestsOnly \
   — basic-level-spec conditions.yaml \
   — policy=EatAndRunPolicy

Connecting the dots with IAP

Once the team set up their access levels, in this case Breakfast, Lunch and Supper for low, medium and high security access, they can use those within IAP to restrict access. Now IAP is checking identity and context in order to decide whether a given request gets to see this App Engine app.

The access levels show up in Access Context Manager

And inside Identity-Aware Proxy, after activating it for the app, the list of identities plus access context can be chosen.

Here’s what a new contractor sees when they try to access the app, without their screenlock even set up (so not even at Breakfast…)

Going further

There’s lots more you can do with Access Policies and Access Context Manager, especially when you plug in your Endpoint Verification data. Try out making a new access policy and access levels yourself, then let me know what other conditions you’re looking to trigger on in the future; this feature keeps evolving as we get feedback.