# Ensure GKE Clusters Are Not Running Using the Compute Engine Default Service Account

- Source: https://support.icompaas.com/support/solutions/articles/62000235314-ensure-gke-clusters-are-not-running-using-the-compute-engine-default-service-account
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [GCP Benchmarks](https://support.icompaas.com/support/solutions/62000112667) › [GCP Knowledge Bases](https://support.icompaas.com/support/solutions/folders/62000169178)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

### **Profile Applicability:**

-   **Level 2**
    

### **Description****:**

Google Kubernetes Engine (GKE) clusters should not use the default Compute Engine service account, as it provides broad permissions that may pose security risks. Instead, it is recommended to configure GKE clusters to use a custom service account with the least required permissions for Kubernetes workloads.

### **Rationale****:**

-   **Principle of Least Privilege**: Using the Compute Engine default service account grants excessive permissions that are not necessary for the GKE cluster's operation. Custom service accounts limit access to only the required resources and actions.
    
-   **Improved Security**: A custom service account with tightly controlled permissions reduces the risk of unauthorized access or privilege escalation within the Kubernetes environment.
    
-   **Compliance**: Many compliance frameworks require the implementation of least-privilege access controls and the restriction of broad permissions.
    

### **Impact****:**

-   **Security**: Using a custom service account enhances security by limiting the permissions granted to the GKE cluster.
    
-   **Operational**: Configuring a custom service account may require changes to IAM roles and policies, which may introduce additional administrative overhead.
    
-   **Compatibility**: Some workloads may require specific permissions, so proper role assignment to the custom service account is essential.
    

### **Default Value****:**

-   By default, GKE clusters are created using the Compute Engine default service account, which has full access to Google Cloud resources.
    

### **Audit Steps****:**

#### **Using Google Cloud Console:**

1.  **Navigate to GKE Clusters**: Go to **Kubernetes Engine** > **Clusters** in Google Cloud Console.
    
2.  **Verify Service Account Configuration**:
    
    -   Select the cluster and click on **Edit**.
        
    -   In the **Node Pools** section, ensure that the **Service Account** used by the node pool is not the **Compute Engine default service account**.
        
3.  **Repeat for All Clusters**: Ensure that no other GKE clusters are using the default service account.
    

#### **Using Google Cloud CLI:**

1.  **List GKE Clusters**:
    
    gcloud container clusters list
    
2.  **Check Service Account for a Cluster**:  
    For each GKE cluster, run:
    
    gcloud container clusters describe \[CLUSTER\_NAME\] --zone \[ZONE\] --format="json" | jq '.nodePools\[\].config.serviceAccount'
    
    -   Ensure that the service account used by the GKE cluster is not the **default service account** (`[PROJECT_NUMBER]-compute@developer.gserviceaccount.com`).
        

### **Remediation Steps:**

#### **Using Google Cloud Console:**

1.  **Navigate to GKE Clusters**: Go to **Kubernetes Engine** > **Clusters**.
    
2.  **Edit Cluster Node Pool**:
    
    -   Select the cluster and click **Edit**.
        
    -   In the **Node Pools** section, select a custom service account for the **Service Account** field (do not use the default service account).
        
3.  **Save Changes**: Click **Save** to apply the changes.
    

#### **Using Google Cloud CLI:**

1.  **Create or Update the Cluster to Use a Custom Service Account**:  
    To create a new GKE cluster with a custom service account:
    
    gcloud container clusters create \[CLUSTER\_NAME\] --zone \[ZONE\] --service-account \[CUSTOM\_SERVICE\_ACCOUNT\]
    
    To update an existing GKE cluster's node pool:
    
    gcloud container clusters upgrade \[CLUSTER\_NAME\] --zone \[ZONE\] --service-account \[CUSTOM\_SERVICE\_ACCOUNT\]
    
2.  **Assign Appropriate Roles to the Custom Service Account**:  
    Ensure that the custom service account has the necessary roles for the GKE nodes. For example:
    
    gcloud projects add-iam-policy-binding \[PROJECT\_ID\] --member "serviceAccount:\[CUSTOM\_SERVICE\_ACCOUNT\]" --role "roles/container.nodeServiceAccount"
    

### **Backout Plan****:**

1.  **Revert to the Default Service Account**:  
    If you need to revert to using the default service account, use the following command:
    
    gcloud container clusters upgrade \[CLUSTER\_NAME\] --zone \[ZONE\] --service-account \[DEFAULT\_SERVICE\_ACCOUNT\]
    
    -   Where `[DEFAULT_SERVICE_ACCOUNT]` is the default Compute Engine service account (`[PROJECT_NUMBER]-compute@developer.gserviceaccount.com`).
        
2.  **Verify the Change**:  
    After reverting, run the `describe` command again to ensure the service account has been restored to the default:
    
    gcloud container clusters describe \[CLUSTER\_NAME\] --zone \[ZONE\] --format="json" | jq '.nodePools\[\].config.serviceAccount'
    
3.  **Test Cluster Operation**:
    
    -   Ensure that the cluster is operational and workloads are correctly running after the change.
        
4.  **Notify Stakeholders**:
    
    -   Inform relevant teams about the backout and any operational impact it may have.
        

### **References****:**

-   Google Cloud Kubernetes Engine IAM and Service Accounts
    
-   GKE Service Accounts Documentation
    

### **CIS Controls****:**

| 
**Control**

 | 

**Description**

 | 

**IG 1**

 | 

**IG 2**

 | 

**IG 3**

 |
| --- | --- | --- | --- | --- |
| 

**5.1**

 | 

Ensure Secure Configurations

 | 

✅

 | 

✅

 | 

✅

 |
| 

**16.5**

 | 

Centralize and Manage Access

 | 

✅

 | 

✅

 | 

✅

 |

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.