Source URL: https://cloud.google.com/blog/products/containers-kubernetes/new-dns-based-endpoint-for-the-gke-control-plane/
Source: Cloud Blog
Title: A new flexible DNS-based approach for accessing the GKE control plane
Feedly Summary: If you run Google Kubernetes Engine (GKE), you know it’s important to secure access to the cluster control plane that handles Kubernetes API requests, so you can prevent unauthorized access while still being able to control the cluster.
Previously, GKE provided two primary methods to secure the control plane: authorized networks and disabling public endpoints. But when using these methods, it can be difficult to access the cluster. You need creative solutions such as bastion hosts to gain access via the cluster’s private network, and the list of authorized networks must be kept up to date across all clusters.
Today, we are excited to announce a new DNS-based endpoint for GKE clusters, allowing enhanced flexibility in access methods and security controls. The DNS-based endpoint is available today on every cluster, regardless of version or cluster configuration.
aside_block
The new DNS-based endpoint addresses several of the current challenges associated with Kubernetes control plane access, including:
Complex IP-based firewall / allowlist configurations: IP address-based authorized network configuration / ACL is prone to human configuration error.
Static configurations based on IP addresses: As network configuration and IP ranges change, you need to change the authorized network IP Firewall configuration accordingly.
Proxy / bastion hosts: When accessing the GKE control plane from a remote network, different cloud location, or from a VPC that is different from the VPC where the cluster resides, you need to set up a proxy or bastion host.
These challenges have resulted in a complex configuration and a confusing user experience for GKE customers.
Introducing a new DNS-based endpoint
The DNS name resolves to a frontend that is accessible from any network that can reach Google Cloud APIs, including VPC networks, on-premises networks, or other cloud networks. This frontend The new DNS-based endpoint for GKE provides a unique DNS or fully qualified domain name (FQDN) for each cluster control plane. applies security policies to reject unauthorized traffic, and then forwards traffic to your cluster.
This approach provides a number of benefits:
1. Simple flexible access from anywhere
Using the DNS-based endpoint eliminates the need for a bastion host or proxy nodes. Authorized users can access your control plane from different clouds, on-prem deployments or from home without jumping through proxies. With DNS-based endpoints, there are no restrictions for transiting multiple VPCs, as the only requirement is access to Google APIs. If desired, you can still limit access to specific networks using VPC Service Controls.
2. Dynamic security
Access to your control plane over the DNS-based endpoint is protected via the same IAM policies used to protect all GCP API access. Using IAM policies, you can ensure that only authorized users can access the control plane, irrespective of which IP or network they use. If needed, you can simply revoke a particular identity’s access without worrying about network IP address configuration and boundaries. IAM roles can be customized to suit your organization’s needs.
For more details on the exact permissions required to configure IAM roles policies and authentication tokens, see Customize your network isolation.
3. Two layers of security
In addition to IAM policies, you can also configure network-based controls with VPC Service Controls, providing a multi-layer security model for your cluster control plane. VPC Service Controls adds context-aware access controls based on attributes such as network origin. You can achieve the same level of security as a private cluster that can only be accessed from a VPC network. VPC Service Controls are used by all Google Cloud APIs, aligning the security configuration of your clusters with your services and data hosted in all other Google Cloud APIs. You can make strong guarantees about preventing unauthorized access to services and data for all Google Cloud resources in a project. VPC Service Controls integrate with Cloud Audit Logs to monitor access to the control plane.
In our customer’s voice:
“When using private IP based control plane access we had to configure and manage a complex networking solution to be able to access the GKE control plane from our various VPC and data center sites. DNS-based GKE control plane access, in partnership with VPC Service Controls, will greatly simplify our access to the GKE control plane and help us implement a dynamic security based access policy based on Identity and Authentication.” – Keith Ferguson – ANZx Cloud & Engineering Platforms Technology Lead, ANZ Bank
How to configure DNS-based access
Configuring DNS-based access for the GKE cluster control plane is a straightforward process. Check out the following steps.
1. Enable the DNS-based endpoint
Enable DNS-based access for a new cluster with the following command:
code_block
<ListValue: [StructValue([(‘code’, ‘$ gcloud container clusters create $cluster_name -–enable-dns-access’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e44b811aaf0>)])]>
Alternatively, enable DNS-based access for an existing cluster with the following command:
code_block
<ListValue: [StructValue([(‘code’, ‘$ gcloud container clusters update $cluster_name –enable-dns-access’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e44b811afd0>)])]>
2. Configure IAM
Access to the control plane requires requests to be authenticated with a role with the new IAM permission container.clusters.connect. Assign one of the following IAM roles to your user:
roles/container.developer
roles/container.viewer
Here is an example of configuring a user to access cluster with pre-configured roles:
Alternatively, you can configure a custom IAM role with the container.clusters.connect permission.
Here’s an example of configuring a role to use container.clusters.connect:
3. Ensure your client can access Google APIs
If your client is connecting from a Google VPC, you will need to ensure that it has connectivity to Google APIs. One way to do this is to activate Private Google Access, which allows clients to connect to Google APIs without going over the public internet. Private Google Access is configured on individual subnets.
Tip: Private Google Access is already enabled for node subnetworks.
Below, you can see an example of turning on Private Google Access in a subnet:
4. [Optional] Configuring access via Private Service Connect for Google APIs
Cluster’s DNS endpoint can be accessible via Private Service Connect for Google APIs endpoint used for accessing the rest of the Google APIs. The Access Google APIs through endpoints page has all required steps to configure Private Service Connect for Google APIs endpoint. Accessing cluster’s DNS via custom endpoint is not supported, therefore as explained in use an endpoint section, creating an A record between “* gke.goog” and private IP assigned to Private Service Connect for Google APIs and creating a CNAME to “*.gke.goog” is required to make it work.
Try out DNS-based access
Now you’re ready to try out DNS-based access. Use the following command to generate a kubeconfig file using the cluster’s DNS address:
code_block
<ListValue: [StructValue([(‘code’, ‘gcloud container clusters get-credentials $cluster_name –dns-endpoint’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e44b811ae80>)])]>
Then, use kubectl to access your cluster. You can use this directly from Cloud Shell to access clusters without a public IP endpoint, something that required setting up a proxy before.
Additional security with VPC Service Controls
Optionally, you can also use VPC Service Controls as an additional layer of security for your control plane access.
Here’s an example of an ingress policy that only allows requests from VMs in a specific GCP project:
What about the IP-based endpoint?
Of course, you can still use the existing IP-based endpoint to access the control plane, allowing you to try out DNS-based access without affecting your existing clients. Then, once you’re happy with DNS-based access, you can disable IP-based access, which provides additional security and simplified cluster management:
code_block
<ListValue: [StructValue([(‘code’, ‘gcloud container clusters update $cluster_name –enable-ip-access=false’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e44b811ad30>)])]>
What’s next
With DNS-based endpoints, you gain increased flexibility in managing the security of your cluster control planes, while also reducing the complexity of accessing clusters from private networks.
To learn more about how to use DNS-based endpoints, check out these references:
Cluster isolation concept page
Cluster isolation how-to page
AI Summary and Description: Yes
Summary: The introduction of DNS-based endpoints for Google Kubernetes Engine (GKE) clusters significantly improves the security and flexibility of accessing Kubernetes control planes. This innovation addresses longstanding challenges associated with IP-based access methods, such as complex firewall configurations and reliance on bastion hosts, leading to a more streamlined user experience for cloud security professionals.
Detailed Description:
The text discusses a critical enhancement to Google Kubernetes Engine (GKE) related to access control and security for Kubernetes API requests:
– **Introduction of DNS-based Endpoint**:
– The transition from traditional IP-based methods to a DNS-based endpoint simplifies access to GKE’s control plane, broadening access options without compromising security.
– **Challenges with Previous Methods**:
– **Complex Configurations**: The previous reliance on IP-based firewalls and authorized networks resulted in complicated configurations and human errors.
– **Static IP Dependency**: Organizations faced issues adapting to changing IP ranges, necessitating frequent updates to firewall configurations.
– **Proxy Requirements**: Accessing the control plane from different networks often required setting up additional bastion hosts, complicating connectivity and security.
– **Key Benefits of the DNS-based Endpoint**:
1. **Flexible Access**:
– Users can access the control plane from various networks without requiring proxy nodes, as long as they can reach Google Cloud APIs.
2. **Dynamic Security**:
– Access policy enforcement is integrated with Google Cloud IAM, allowing easy customization of roles and the ability to revoke access without needing to update network configurations.
3. **Multi-layer Security**:
– The option to implement VPC Service Controls adds an additional security layer, allowing context-aware access based on network origin.
– **User Feedback**:
– A quote from Keith Ferguson of ANZ Bank highlights the reduced complexity and improved security for managing GKE access due to this new approach.
– **Configuration Steps**:
– The text outlines practical steps for enabling DNS-based access and configuring IAM roles, emphasizing ease of implementation for users.
– **Optional Enhancements**:
– Additional configurations such as Private Google Access and Private Service Connect are discussed for those seeking further security enhancements.
– **Support for Existing Models**:
– Users can still operate using existing IP-based methods to ensure a smooth transition to DNS-based access without immediate disruption to their current configurations.
In conclusion, the introduction of DNS-based endpoints for GKE represents a significant advancement in cloud infrastructure security and access management, highlighting practical implications for security professionals seeking to streamline operations while enhancing security measures.