BeyondCorp vs BeyondProd
First of all, the graph is misleading because ACM does not really enforce any requests, that’s just where you define access levels, instead a conditional IAM policy based on that access level applied to IaP does. Also buckets are not resources you grant access to with IaP as far as I know. So I don’t understand why that’s there. I think it means you can front it with your own API hosted in Cloud Run or something like that — weird.
Another thing I don’t understand about BeyondCorp Documentation is that they don’t list VPC Service Controls as one of the offerings. But it should be, especially since the only way to restrict access to multiple services based on device attributes via de console effectively seems to be to creating a perimeter and enabling BeyondCorp Enterprise.
For example if your intention was to restrict access to BigQuery, you would not be able to do this IAM Conditional policies since they only affect IaP and IaP is not a tool designed for this, hence you would need VPC Service controls.
Of course perhaps it is just me who misunderstands the documentation and therefore no one else has any difficulty getting it, but just in case, this post aims to save all the lost souls in BeyondCorp confusion purgatory.
This article does not cover DLP.
What is the BeyondCorp Model?
It is important to know the difference between BeyondCorp, the security model, and BeyondCorp Enterprise, the GCP offering. The model is just an infrastructure set of recommendations that aims to achieve the following:
- Context Aware Security, not just who, but where, what and how. You validate the user, their device attributes and where they are connecting from.
- No VPNs, no moats. VPNs are a bottleneck and are a single point of failure in terms of availability and security.
- No implicit trust inside the network for users. With VPNs, many organisations assume implicit trust once you connect. The BeyondCorp model validates credentials in every layer.
- More Dynamic approach to security as users don’t need to rely on VPNs, different access levels can be configured depending on how they connect.
The BeyondCorp model itself doesn’t prescribe any particular tool to implement it, it’s just the way that Google does their security and how they recommend you should do it.
What is BeyondCorp Enterprise?
The BeyondCorp Enterprise offering is a set of tools and features that GCP provides that enable you to easily implement the BeyondCorp Model in your organisation. We will go over these in the next section of this post.
How does BeyondCorp Enterprise work?
The four most important products and features that you need to familiarize yourself in order to implement BeyondCorp are the following:
- Access Context Manager
- VPC Service Controls
- Identity Aware Proxy (IaP)
- IAM conditional Policies
Access Context Manager (ACM)
In ACM you create a policy that applies to the entire organization, and within that policy you set access levels. Access Levels filter requests to resources based on attributes you define (Example YAML). For example you can grant access based on IP origin, which is free. or you can grant access based on device policy, which is part of BeyondCorp Enterprise (not free).
You can get device information from a user request by using Endpoint Verification, which works on multiple devices, such as Mac, Windows, IPhone, Android, etc. EV can tell whether your device could be compromised by malware, is encrypted, the screen is locked, etc. All those device attributes can be used to define whether someone is granted access or not.
It’s worth pointing out that ACM does NOT enforce any policies, it is just used to define access levels that are enforced at various points, most notably VPC Service Controls and IAM conditions.
VPC Service Controls
With VPC Service Controls you define a security perimeter around the GCP projects and resources you choose. Within this perimeter access is not permitted in or out of it unless you explicitly allow it. Not all GCP services are supported, but the vast majority are. Generally speaking the way you allow someone within your perimeter is with the access levels previously mentioned.
Identity Aware Proxy (IaP)
IaP is used to tunnel traffic inside the resources that you expose through it in your organisation. For example if you needed to be able to access SSH from the outside or a web application, you can authenticate with your credentials to GCP which would then be validated by a conditional IAM policy that is granted to your IaP.
IAM Conditional Policies
IaP requires conditional policies with request attributes from Access Levels in order to determine what to allow and what to deny access to. According to the documentation, these request attributes can only be applied conditionally to IaP and not other resources.
Identity Aware Proxy (IaP) is just a part of BeyondCorp Enterprise
IaP gets often confused with BeyondCorp, but they are not the same thing. IaP is a tool used as part of the BeyondCorp Enterprise offering that allows access to resources inside of your perimeter, such as a server via ssh or server UI. However IaP is not used to access your GCP console and it does not control what GCP resources you can access there. Access to these are usually restricted with VPC service controls.
BeyondCorp Enterprise is not free. However, many of its features are.
BeyondCorp Enterprise is a paid offering but you can use many of its features with basic GCP. The main difference is that without it you will not be able to authenticate based on your device. But you can still use ip origin as one of the attributes for your access levels.
Beyond BeyondCorp — BeyondProd
BeyondProd is an extension of BeyondCorp that stretches the model to also encompass microservices and workloads inside your infrastructure. Where BeyondCorp is about doing away with trusted layers in an organisation and validating user interaction at every level, BeyondProd is about assuming no implicit trust between services and encrypting and validating all communication between them.
In Google’s words:
Where BeyondCorp states that “user trust should be dependent on characteristics like the context-aware state of devices and not the ability to connect to the corp network”, BeyondProd states that “service trust should be dependent on characteristics like code provenance and service identity, not the location in the production network, such as IP or hostname identity”.
BeyondProd is not a paid offering like BeyondCorp Enterprise. It’s just a model for how to extend infrastructure security that aims to achieve the following:
- Protection of the network at the edge
- No inherent mutual trust between services
- Trusted machines running code with known provenance
- Choke points for consistent policy enforcement across services, for example, ensuring authorized data access
- Simple, automated, and standardized change rollout, and
- Isolation between workloads
Even though there isn’t a paid offering called “BeyondProd Enterprise”, GCP offers various tools to achieve all of the above:
- Mutually authenticated service endpoints — Traffic Director
- Transport security — Istio on GKE
- Edge termination with global load balancing and denial of service protection — Cloud Armor and Cloud Load Balancing
- End-to-end code provenance — Binary Authorization
- Runtime sandboxing — GKE sandbox (ironically, this is not compatible with Traffic Director) and Shielded GKE Nodes