The Threat of Security Blind Spots

As organizations have shifted into the cloud, they’ve increasingly relied on CSPM solutions to secure their infrastructure. CSPMs expose security vulnerabilities in cloud environments such as misconfigured storage buckets or insecure firewall configurations.

CSPMs have a major blindspot, though. CSPMs focus purely on securing the cloud infrastructure's core configuration and skip the security of the actual workloads running on servers or Kubernetes clusters. This leaves security misconfigurations and software vulnerabilities in perhaps the most crucial part of your cloud infrastructure.

Mondoo: Full Stack Cloud Security for GCP

Attackers don’t care what team owns a particular part of your infrastructure or where the boundaries lie between KSPM, CPSM, CWPP, or other security tools. They seek out vulnerabilities wherever they exist in your infrastructure. That’s why at Mondoo, we prioritize the security of your complete cloud infrastructure from the cloud account to server workloads and everything in between.

Mondoo’s advanced, open source scanning engine, cnspec, allows you to scan not just your GCP organizations and projects for security misconfigurations but also individual virtual machines and Kubernetes clusters/workloads. Best of all, you can do all this without deploying and managing agents throughout your infrastructure.

‍

Complete GCP Security from the CLI

We’ll start our security journey off from a privileged GCP jump host, where we can install the cnspec CLI with the automated Mondoo installation script:

With cnspec installed, we can start with a scan of our sample GCP project, luna-common, using the cnspec scan gcp project command:

cnspec scan gcp project luna-common
→ loaded configuration from /home/tim/.config/mondoo/mondoo.yml using source default
→ using service account credentials
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1

Asset: GCP project luna-common
------------------------------

Checks:
✕ Fail: C 30 Ensure oslogin is enabled for compute instances
✓ Pass: A 100 Ensure instances are not configured to use the default service account with full access to all Cloud APIs
…
✓ Pass: A 100 Ensure that instances are not configured to use the default service account
✕ Fail: C 30 Ensure "Block Project-wide SSH keys" is enabled for VM instances
✓ Pass: A 100 Ensure that Cloud Storage buckets are not anonymously or publicly accessible
✓ Pass: A 100 Ensure that Cloud Storage buckets have uniform bucket-level access enabled

Scanned 1 assets

GCP Project
 D GCP project luna-common

After completing the initial scan of our GCP project, there are several issues that we need to resolve. Out of the 95 checks from the bundled CIS Google Cloud Platform Foundation and CIS Google Kubernetes Engine policies, 24 have failed. We can dive deeper into these failures with detailed logging to show the complete output of the scans, or we can jump right to the Mondoo Console to graphically explore the results.

Securing VM Instances

Our GCP project is made up of more than just storage buckets and load balancers, though. Let's see how our VM instances are doing. We can scan those instances locally using cnspec directly on the instances or take another agentless approach: SSH, WinRM, or snapshot scanning. Why so many options? At Mondoo we think it's your choice how to best scan your infrastructure, not your vendor's. That means giving you options you need to integrate security into your infrastructure. Our VM instance is particularly sensitive to disruptions, so we'll use snapshot scanning. With snapshot scanning, cnspec automatically creates and scans a snapshot of your VM, so there's no impact on the running instance. You can snapshot scan a GCP VM instance using the cnspec scan gcp instance command.

cnspec scan gcp instance importantserver --project-id luna-common --zone us-west1-b
→ loaded configuration from /home/tim/.config/mondoo/mondoo.yml using source default
→ using service account credentials
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1

importantserver ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% score: C

Asset: importantserver
----------------------

Checks:

✓ Pass:  A 100  Ensure NFS and RPC are stopped and not enabled
✓ Pass:  A 100  Ensure root group is empty
...
✓ Pass:  A 100  Ensure UID_MIN is set to 1000
✕ Fail:  D  20  Ensure system administrator actions (sudolog) are collected
✕ Fail:  F   0  Ensure only strong ciphers are used
✕ Fail:  D  20  Ensure auditd is installed
✕ Fail:  F   0  Ensure source routed packets are not accepted

Scanned 1 assets

Debian GNU/Linux 12 (bookworm)
  C importantserver

This important server instance scored fairly poorly with 125 out of 300 checks in the bundled CIS Debian 11 benchmarks failing. This is an excellent example of security weaknesses in the default GCP images that should be corrected. Building your own hardened custom images with Packer and Mondoo is an excellent first step, but a story for another blog post.

Security Beyond Cloud and Servers

Even with our cloud and server infrastructure fully secured, there are still critical gaps in our infrastructure security: Kubernetes, Kubernetes, Kubernetes! Kubernetes has swallowed the infrastructure world, and traditional CSPM-only solutions lack visibility into the Kubernetes cluster and workload configuration. Once again, with cnspec we can dive deep into the security of the cluster and workloads within the cluster, including the containers running your apps. To scan our cluster and all workloads, we can run cnspec scan k8s, which uses our existing kubectl authentication to scan our cluster.

cnspec scan k8s
→ loaded configuration from /home/tim/.config/mondoo/mondoo.yml using source default
→ using service account credentials
→ discover related assets for 1 asset(s)
→ discovery option auto is used. This will detect the assets: cluster, cronjobs, daemonsets, deployments, ingresses, jobs, pods, replicasets, statefulsets
→ use cluster name from kube config cluster-name=gke_luna-common_us-central1-c_production
→ resolved assets resolved-assets=75

 K8s Cluster gke_luna-common_us-central1-c_production  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% score: D
 gmp-system/gmp-operator                               ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% score: C
...

Kubernetes ReplicaSet
C gmp-system/gmp-operator-855fb88544
C gmp-system/rule-evaluator-6dc998c878
C gmp-system/rule-evaluator-84b694f679
C kube-system/event-exporter-gke-7bf6c99dcb
C kube-system/konnectivity-agent-755467dfb5
C kube-system/konnectivity-agent-autoscaler-5d9dbcc6d8
C kube-system/kube-dns-5bfd847c64
C kube-system/kube-dns-autoscaler-84b8db4dc7
C kube-system/l7-default-backend-d86c96845
C kube-system/metrics-server-v0.5.2-6bf74b5d5f
C kube-system/metrics-server-v0.5.2-8569bc4cf9

Kubernetes StatefulSet
C gmp-system/alertmanager

Summary
=======

Score Distribution          Asset Distribution
------------------          ------------------
A   0 assets                Kubernetes ReplicaSet    11
B   0 assets                Kubernetes Cluster       1 
C  74 assets                Kubernetes StatefulSet   1
D   1 assets                Kubernetes Pod           28
F   0 assets                Kubernetes DaemonSet     25

Our scan found a total of 75 assets between the cluster itself and the various workloads running on the cluster. These assets were evaluated using 230 checks from the CIS Google Kubernetes Engine (GKE) benchmark and the NSA/CISA Kubernetes Hardening Guide Version 1.2. Between these two policies, a number of significant security deficiencies were discovered with our out-of-the-box cluster.

No Kubernetes asset we scanned scored better than a "C" and, to quote my mom, "Be better than average, Tim. Never bring home a C again." Out-of-the-box GKE security is average at best. With these results, we have the help we need to do better. Once we've secured our existing workloads, we can scan container images, Kubernetes manifests, and Terraform configs with Mondoo in CI/CD pipelines to keep our cluster secure.

Secure Your Modern Infrastructure

Attackers and CPSM providers have one thing in common: They don't want you to consider the full breadth and depth of GCP security or the many gaps in a typical solution. Mondoo provides a complete assessment of your GCP security posture and the finely detailed information you need to improve it.

Get full access to Mondoo, a free consultation with our security experts, and all features in the Enterprise edition completely free for 30 days. Start your 30-day trial now!

‍