Skip to main content

🛡️ Google GKE Cluster Control Plane Authorized Networks are disabled🟢

Stats​

not available

Logic​

Similar Policies​

  • Internal: dec-x-30a00a24

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-30a00a241

Description​

Open File

Description​

This policy identifies Google GKE Clusters where Control Plane Authorized Networks are not enabled. Enabling this feature restricts access to the cluster’s control plane to a defined allowlist of trusted IP addresses.

Rationale​

Control Plane Authorized Networks improve cluster security by limiting which IP addresses can access the Kubernetes API server.

Key benefits include:

  • Restricts external, non-GCP access to a specified set of IP addresses (e.g., corporate office ranges), reducing exposure in the event of a vulnerability in authentication or authorization mechanisms.
  • Helps mitigate risks from leaked master certificates by ensuring they cannot be used from unauthorized IP ranges.
  • Allows administrators to enforce strict access policies while still permitting trusted GCP traffic (e.g., Compute Engine VMs).

Impact​

When implementing Control Plane Authorized Networks, ensure all required networks are included in the allowlist, otherwise legitimate external access to the cluster’s control plane may be inadvertently blocked.

... see more

Remediation​

Open File

Remediation​

Enable Control Plane Authorized Networks​

Using gcloud CLI​

To enable Control Plane Authorized Networks for an existing cluster, run the following command:

```sh
gcloud container clusters update {{cluster-name}} \
    --location {{location}} \
    --enable-master-authorized-networks
```

You can also specify the allowed IP ranges using the --master-authorized-networks flag. This flag accepts a comma-separated list of CIDR blocks (up to 100 for private clusters, 50 for public clusters).

These authorized networks define the IP addresses permitted to access your cluster’s control plane via HTTPS.

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 36b configuration management —the configuration of information assets minimises vulnerabilities and is defined, assessed, registered, maintained, including when new vulnerabilities and threats are discovered, and applied consistently;33no data
💼 CIS GKE v1.8.0 → 💼 5.6.3 Ensure Control Plane Authorized Networks is Enabled (Automated)1no data
💼 Cloudaware Framework → 💼 Secure Access61no data
💼 HIPAA Security Rules → 💼 164.312(e)(2)(i) Integrity Controls (A)22no data
💼 ISO/IEC 27001:2013 → 💼 A.14.1.1 Information security requirements analysis and specification77no data
💼 NIST CSF v1.1 → 💼 PR.IP-2: A System Development Life Cycle to manage systems is implemented710no data
💼 PCI DSS v3.2.1 → 💼 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.16111no data
💼 PCI DSS v3.2.1 → 💼 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.10100no data
💼 PCI DSS v3.2.1 → 💼 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.100no data
💼 PCI DSS v3.2.1 → 💼 1.3.5 Permit only “established” connections into the network.100no data
💼 PCI DSS v4.0.1 → 💼 1.3.1 Inbound traffic to the CDE is restricted.111no data
💼 PCI DSS v4.0.1 → 💼 1.3.2 Outbound traffic from the CDE is restricted.111no data
💼 PCI DSS v4.0.1 → 💼 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.100no data
💼 PCI DSS v4.0 → 💼 1.3.1 Inbound traffic to the CDE is restricted.31111no data
💼 PCI DSS v4.0 → 💼 1.3.2 Outbound traffic from the CDE is restricted.111no data
💼 PCI DSS v4.0 → 💼 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.31100no data
💼 SOC 2 → 💼 CC7.1-1 Uses Defined Configuration Standards56no data