DNS-Based Endpoints
In order to prevent unwanted access while maintaining cluster management, it is crucial to restrict access to the cluster control plane, which processes Kubernetes API calls, as you are aware if you use Google Kubernetes Engine (GKE).
Authorized networks and turning off public endpoints were the two main ways that GKE used to secure the control plane. However, accessing the cluster may be challenging when employing these techniques. To obtain access through the cluster’s private network, you need to come up with innovative solutions like bastion hosts, and the list of permitted networks needs to be updated for every cluster.
Google Cloud is presenting a new DNS-based endpoint for GKE clusters today, which offers more security restrictions and access method flexibility. All clusters have the DNS-based endpoint available today, irrespective of cluster configuration or version.
Several of the present issues with Kubernetes control plane access are resolved with the new DNS-based endpoint, including:
- Complex allowlist and firewall setups based on IP: ACLs and approved network configurations based on IP addresses are vulnerable to human setup error.
- IP-based static configurations: You must adjust the approved network IP firewall configuration in accordance with changes in network configuration and IP ranges.
- Proxy/bastion hosts: You must set up a proxy or bastion host if you are accessing the GKE control plane from a different cloud location, a distant network, or a VPC that is not the same as the VPC where the cluster is located.
Due to these difficulties, GKE clients now have to deal with a complicated configuration and a perplexing user experience.
Introducing a new DNS-based endpoint
Any network that can connect to Google Cloud APIs, such as VPC networks, on-premises networks, or other cloud networks, can access the frontend that the DNS name resolves to. This front-end Each cluster control plane has its own DNS or fully qualified domain name (FQDN) with the new DNS-based endpoint for GKE routes traffic to your cluster after using security policies to block unwanted traffic.
This strategy has several advantages:
Simple flexible access from anywhere
Proxy nodes and bastion hosts are not required when using the DNS-based endpoint. Without using proxies, authorized users can access your control plane from various clouds, on-premises deployments, or from their homes. Transiting various VPCs is unrestricted with DNS-based endpoints because all that is needed is access to Google APIs. You can still use VPC Service Controls to restrict access to particular networks if you’d like.
Dynamic Security
The same IAM controls that safeguard all GCP API access are also utilized to protect access to your control plane over the DNS-based endpoint. You can make sure that only authorized users, regardless of the IP address or network they use, may access the control plane by implementing identity and access management (IAM) policies. You can easily remove access to a specific identity if necessary, without having to bother about network IP address bounds and configuration. IAM roles can be tailored to the requirements of your company.
See Customize your network isolation for additional information on the precise permissions needed to set up IAM roles, rules, and authentication tokens.
Two layers of security
You may set up network-based controls with VPC Service Controls in addition to IAM policies, giving your cluster control plane a multi-layer security architecture. Context-aware access controls based on network origin and other attributes are added by VPC Service Controls. The security of a private cluster that is only accessible from a VPC network can be equaled.
All Google Cloud APIs use VPC Service Controls, which ensures that your clusters’ security setup matches that of the services and data hosted by all other Google Cloud APIs. For all Google Cloud resources used in a project, you may provide solid assurances for the prevention of illegal access to data and services. Cloud Audit Logs and VPC Service Controls work together to track control plane access.
How to configure DNS-based access
The procedure of setting up DNS-based access for the GKE cluster control plane is simple Check the next steps.
Enable the DNS-based endpoint
Use the following command to enable DNS-based access for a new cluster:
$ gcloud container clusters create $cluster_name –enable-dns-access
As an alternative, use the following command to allow DNS-based access for an existing cluster:
$ gcloud container clusters update $cluster_name –enable-dns-acces
Configure IAM
Requests must be authenticated with a role that has the new IAM authorization in order to access the control plane.
roles/container.developerroles/container.viewer
Ensure your client can access Google APIs
You must confirm that your client has access to Google APIs if it is connecting from a Google VPC. Activating Private Google Access, which enables clients to connect to Google APIs without using the public internet, is one approach to accomplish this. Each subnet has its own configuration for private Google Access.
Tip: Private Google Access is already enabled for node subnetworks.
[Selective] Setting up access to Google APIs via Private Service Connect
The Private Service Connect for Google APIs endpoint, which is used to access the other Google APIs, can be used to access the DNS endpoint of the cluster. To configure Private Service Connect for Google APIs endpoints, follow the instructions on the Access Google APIs through endpoints page.
Since using a custom endpoint to access the cluster’s DNS is not supported, as detailed in the use an endpoint section, in order to get it to work, you must create a CNAME to “gke.goog” and an A record between “gke.goog” and the private IP allocated to Private Service Connect for Google APIs.
Try DNS access
You can now try DNS-based access. The following command generates a kubeconfig file using the cluster’s DNS address:
gcloud container clusters get-credentials $cluster_name –dns-endpoint
Use kubectl to access your cluster. This allows Cloud Shell to access clusters without a public IP endpoint, previously required a proxy.
Extra security using VPC Service Controls
Additional control plane access security can be added with VPC Service Controls.
A GCP project-specific ingress policy permits only VM requests:
What about the IP-based endpoint?
You can test DNS-based control plane access without affecting your clients by using the IP-based endpoint. After you’re satisfied with DNS-based access, disable IP-based access for added security and easier cluster management:
gcloud container clusters update $cluster_name –enable-ip-access=false
