GKE for Regulated Workloads

The most frequently cited downside of using Kubernetes is almost always the operational overhead. Node management, upgrade cycles, scaling configurations, and the endless YAML manifests quickly begin to chip away at a team’s ability to operate efficiently. Google Kubernetes Engine (GKE) has been working on solving some of these operational overhead problems for more than a decade and has matured to the point where we have real solutions for most of those complaints. However, it’s important to note, that a “managed” or even “fully managed” platform does not mean “zero decisions.” This post will help frame how you should think about GKE today, especially if you’re supporting workloads with requirements that fall under FedRAMP or other highly regulated industries.

 

GKE offers two primary modes of operation, Autopilot and Standard mode. Google now recommends Autopilot mode as the default. In which, Google will handle the node provisioning, scaling, upgrades, and security hardening of the nodes. Your responsibility is to define what your workloads will need via your pod specs. GKE figures out the infrastructure. Billing on Autopilot is done primarily on a per-pod basis by charging for the vCPU, memory, and ephemeral storage resources requested by the running pods rather than billing for the underlying node Compute Engine instance based on the machine type. This helps to avoid paying for idle resources. However, if your spec selects specific hardware then those pods will use a node-based billing model. Autopilot clusters come preconfigured with Workload Identity, shielded nodes, and secure boot features enabled by default.

 

Standard mode abstracts away less of the cluster management responsibilities from the user. It will be useful when you need more granular control over node pools, specific images, custom instance types, or the ability to run workloads in the kube-system namespace. You manage the nodes and pay for the underlying Compute Engine VMs regardless of the utilization.

 

There is also now a new way of running workloads in GKE that is worth noting. A new “hybrid” option allows you to run Autopilot workloads inside of a Standard cluster. This is achieved by offering ComputeClasses. You can specify an Autopilot ComputeClass for the workload to run on. This means that you can run some workloads fully managed by Google while keeping others under manual control. All within the same cluster. This offers a practical solution for teams with mixed requirements between stateless microservices and those workloads that require specific hardware.

For teams that are supporting FedRAMP workloads, GKE has a strong compliance posture. GKE is included in GCP’s FedRAMP High provisional Authority to Operate (ATO). This is the highest bar for FedRAMP compliance and means that GKE can be used within the authorization boundary of lower level FedRAMP ATO designations as well.

 

The setup for FedRAMP workloads involves using Assured Workloads in GCP. This enforces guardrails within a GCP project such as US only data residency, restricted support access to the appropriate personnel, and applies FIPS 140-2 compliant encryption by default. You will not need to manage any OS-level encryption to satisfy the FedRAMP requirements for data protection at rest and in transit since it is baked into the platform by using Assured Workloads.

 

GKE has reached a level of maturity where the “build vs buy” question for managed Kubernetes clusters becomes clearer for most teams. The hybrid approach helps reduce operational burden without sacrificing control where you need it. You no longer have to pick one mode for the entire cluster. These operational improvements combined with Assured Workloads in GCP make it easier to run regulated workloads in the cloud by inheriting a significant portion of the control baseline from the platform itself. Leading to less documentation and fewer audit findings.