Google Identity-Aware Proxy
cloud.google.comAs you can sort-of see from the linked site, this is a public version of what Google uses internally, which is called BeyondCorp[0].
It's really an amazing way to think about security for a company. If you deploy it universally across your company, VPNs become obsolete. This solves a popular attack vector where bad-actors just need to get onto a corporate network to do damage. If you can authenticate at every service your employees connect to, it closes down that vector.
As far as I remember BeyondCorp required users to be equipped only with attested hardware (no BYOD). This device's health then was constantly being monitored and taken into account when granting / denying access. I'd like to see the differences between IAP and Google's internal BeyondCorp. Quick search did not reveal anything.
The only BYOD device allowed is Chromebooks with a signed bootloader, aka no developer mode or Crouton.
Unless you modify the hardware, of course.
Considering Google has teams designing custom PCBs and even ICs, there's a non-insignificant amount of Google devs who could easily circumvent this entire system.
The purpose of ascertaining device identity is to prevent someone who can't obtain legitimate Google issued hardware from using stolen user credentials. If you're already a Google employee you can just ask for more trusted hardware, so there would be little point in breaking that part of the security model.
Well, there was recently a case where one of the developers for Google's custom LIDAR hardware stole the plans and gave them to Uber.
And people argued he had no option to hide it.
As I mentioned there, too, it's trivial to break that security if you have the knowledge to design and reverse custom ICs, and you could just steal the laptop of someone else, clone their trusted hardware system, and ensure their laptop is back in place.
Then later use that account to download the data to be sent to Uber.
I mean, for many cases of corporate espionage this is easily doable — it's just fancy DRM, after all. Not by the average dev, but for people who design this hardware or similar hardware in the first place, definitely.
Google's model requires two factor user auth, and trusted hardware.
Even someone with serious hardware-foo would only be able to maybe break the trusted hardware bit (by cloning one device id to another, or emulating a device). They couldn't get round the two factor authentication bit.
I'd say it's still a pretty watertight model.
Like many things, I'm sure you can make a case for exceptions or whitelists --although granted they likely monitor and or shunt traffic to less trusted vlans or something?
The ultimate BeyondCorp setup has no vlans. All networking kit is considered untrusted (and can be the public internet). All traffic is end to end encrypted between the employees device and the specific server they want to communicate with via HTTPS.
Obviously, getting entirely to that model is a lot of work, mostly for services which don't use HTTPS (network shares, ftp, smtp, ssh, enterprise java apps, etc.)
I think that's why the describe this as "...a building block toward BeyondCorp..." We'd pay for them to develop a service that did the whole 9 yards (multi-platform agents, CA, client-certs, etc.).
In general, you can prevent BYOD with this approach by rolling out client certificates with config management and requiring them at the proxy.
And the client certs can be tpm backed so they can't be copy+pasted to other machines.
Part of the announcement was that additional contextual auth capabilities would be added.
i really dont get what this is. is it not web based auth? why are VPNs obsolete? this does not co-exist with VPNs? how is this different from , say, shiboleth or other saml or sso schemes?
I'm super happy to see this. Square uses something similar for employee access to our datacenter, and I hope more people follow this trend. It's one of the annoying parts of open-sourcing our infrastructure -- we can't generally assume folks have an authenticating proxy around. With a few examples in the wild, I'll be happy to start doing that.
We use mutually-authenticated TLS (ie, the proxy presents a client cert to your backend) so that you know the entire request is valid, including the username header. IAP only signs the header, which could be replayed because it's not bound to the session (eg, a debug page exposes request headers). But it's probably easier to grab a library that can validate JWT than worry about your TLS termination layer (eg, in a rails app behind nginx terminating TLS & serving asssets)
Have you seen https://github.com/bitly/oauth2_proxy?
I love that thing - I use it with nginx to secure access to stuff running on my home machine that I want to expose publicly (e.g. the Transmission Web UI).
Wouldn't something like Caddy's multipass[1] be easier and with less third-party approval?
That said, I just use Caddy to proxy all my home's internal services with basic auth. At work I use the same setup, except it authenticates against our LDAP server.
That's a great use for it I hadn't considered. Thanks for the idea.
What types of webservices? Just pure L7 stuff that has forms on it? Is that oauth2proxy just an authenticated reverse proxy or can it add some security context to the internal interface?
We use it in conjunction with kubernetes service proxy https://github.com/pedro-r-marques/k8s-service-proxy to access all of our internal services and debug ports deployed in the k8s/GKE cluster. oauth2 proxy authenticates, service discovery in k8s means that we can keep publishing apps. We don't use fine grain ACLs... But i guess that we could if we wanted to.
I'm a big fan. Ive been using it to do 'outside in' google type, expose services on the internet via oauth for ages. Its solid and great.
I hadn't before this thread. It looks cool. I'm definitely going to look into it more. Thanks!
For a recent service I wrote, it requires the JWT to expire in less than a minute.. which would at least minimize replay attacks and entirely possible to do something similar.
Though client certs is definitely safer all around, more involved to spread around to apps talking to each other though.
Happy to see BeyondCorp start to catch on. We've been champions for a while at ScaleFT. In fact, we're hosting a BeyondCorp Meetup tonight in SF. There will be a couple talks on the subject that should be of interest to folks here. It's an open event with RSVP, so come by if you're around.
Oh, did this just launch today? That's funny, I thought I only noticed it today. In any case, I'm using it already. I was going to build SAML into this app that we have deployed on GCE, so that employees can access it over the internet as long as they're authenticated, but instead I put it behind an IAP, and our Google auth already talks to our SAML server, so Google is effectively doing the same work for us.
Can anyone recommend this?
Yea! It's awesome. We have a kubernetes chart for it available here: https://github.com/cloudposse/charts/tree/master/incubator/o...
I've also used it internally, works great.
Is there any good way to configure it to handle many subdomains with one instance, or do you still have to pick between using one primary proxy.tld vs. running lots of instances of the proxy?
I've used it for an internal project and it worked really well. Simple and easy to follow instructions.
Seems like a cool service, but not really a fan that the acronym mirrors a different service from AWS (Identity and Access Management.) Could be confusing.
Because Google Cloud already has had IAM for some time: https://console.cloud.google.com/iam-admin/iam
As with AWS IAM, it manages access to the infrastructure, like your machine instances.
But this new Google thing, as far as I understand, is about giving other (potentially non-technical) users access to your corporate resources using single identity.
If this really works as they claim, it's a big reprieve from the VPN crap I have been dealing with since years.
Is there similar service in AWS?
Does this serve a similar function to e.g. https://getkong.org/ ?
What is a difference between proxy and a VPN?
layering differences aside, there's a fairly important security difference here:
Because the proxy is examining requests, it can authorize them, and provide data to the back-end about what user was authenticated. A VPN usually just gets you onto the network, and doesn't provide much if any data to the service being accessed about what user and application is connecting.
A VPN is generally invisible to both sides of the communication, so you can tack on extra security, but it's harder to have the applications actually rely on it for authn/authz guarantees. In practice this means you have to log in twice: Once to the VPN, and again to the application. There's some ways to make that invisible to the user, though.
Lets you have a whitelist of accounts per serivce. for example your HR payroll site can have IAP sitting in front of the site. IAP can only allow managers & hr access where-as the underlying system might not have this identity protection.
You can then have different whitelists per service.
Also IAP doesn't require the use of a VPN client. All one needs is a web browser with an internet connection. Giving your workers freedom to access corp assets just about anywhere.
VPNs are also much more expensive to maintain (good VPN hardware isn't cheap), introduce much more network latency and are another thing for help desk personnel to have to support (read: spend money supporting).
BeyondCorp/UberProxy is just a really complicated whitelist. That's it. Super simple.
Traditionally a VPN operates at the IP layer, while a proxy operates at the application layer. For example, a VPN will provide an IP route that you can send any kind of packets over, while an HTTP proxy speaks the actual HTTP protocol and makes HTTP requests on your behalf.
Can someone list a Use Case? I don't get it much how I should use this service. Should I connect to it to have access to server? remote machines? or be inside a network? Or should/could It be used to authorize users of a service to access determinated urls of a web app?
Thoughts on how this compares to something like Azure AD Application Proxy? Seems cheaper at least!
If anyone needs something like this for Heroku, you check my add-on: https://elements.heroku.com/addons/wwwhisper
How does this compare/relate with LastPass?
Ones a password manager, the other is a proxy. Apples and dump trucks, completely different purposes.