Exploring container security: Protecting and defending your Kubernetes Engine network
Manjot Pahwa
Product Manager, Google Cloud, Google
Ahmet Balkan
Developer Experience Engineer, Cloud Networking
Editor’s note: This is the fourth in a series of blog posts on container security at Google. You can find the other posts in the series here.
Security is a crucial factor in deciding which public cloud provider to move to—if at all. Containers have become the standard way to deploy applications both in the public cloud and on-premises, and Google Kubernetes Engine implements several best practices to ensure the security and privacy of your deployments. In this post, we’ll answer some of your questions related to container networking security of Kubernetes Engine, and how it differs from traditional VM networking security.
Kubernetes’ design greatly simplifies networking by abstracting management of load balancer and firewall configurations. In addition, Kubernetes Engine also offers a variety of network security tools to help you lock down your network:
- Private Clusters gives your workloads private RFC 1918 IP addresses, taking them off the public internet. Authorized networks let you restrict access to your masters to a specific set of IP address ranges.
- Virtual Private Cloud (VPC) Networks provide private global connectivity between your resources, including Kubernetes Engine clusters, offering flexibility in managing your deployment with respect to IP address management, firewalls and routes.
- VPC service controls allow you to restrict the access to the data from trusted network sources and mitigate data exfiltration risks.
- Kubernetes Network Policies let you restrict pod to pod traffic in your Kubernetes cluster, giving you the ability to isolate your microservices from one another and from the outside world.
- Encryption for data in transit as it moves across a physical boundary is standard across Google Cloud Platform (GCP).
- Secure access for GCP services from your on-premises deployments using Private Google Access and secure connection to your GCP deployments using our advanced peering capabilities to allow no traffic to transit through the internet.
- Layer 7 Protection with support for HTTPS with Ingress on Kubernetes Engine. Protection against DDoS and other layer 4 attacks such as SYN floods through Google Cloud HTTP(S) and TCP load balancers.
Google Cloud offers a wealth of services and functionality to help you lock down the network connected to your Kubernetes Engine clusters. Let’s drill down into each of these offerings a bit further.
Isolate your workload from the public web using Private Clusters (beta)
We recently announced the beta availability of Kubernetes Engine Private Clusters, allowing you to deploy clusters privately as part of your Google VPC and your nodes with only private RFC 1918 IP addresses. Private Clusters ensures network segmentation, reducing the scope and complexity of PCI-DSS compliance. Learn more about the specific segmentation requirements for PCI DSS.
Learn more about Private Clusters.
Restrict access to your master using Authorized Networks (beta)
By default, Kubernetes Engine uses both Transport Layer Security (TLS) and IAM authentication to provide secure access to your master endpoint from the public internet. Authorized Networks give you additional protection by allowing a whitelisted range of IP addresses access to your master endpoint, blocking uncontrolled network access. Note that if you’re using a Private Cluster, your master endpoint will use Authorized Networks by default.Run your Kubernetes Engine cluster in a global Virtual Private Cloud
Traditional VPCs are regional connected silos that must be stitched together through either the public internet or VPN, leading to a sprawl of connections to your on-premises deployment. Google’s VPC offers global connectivity for all your GCP workloads (e.g. Compute Engine VMs and Kubernetes clusters), removing the need for public internet routing or extra VPNs.
Restrict pod-to-pod traffic with a Kubernetes Network Policy
Kubernetes Network Policies allow you to restrict pod-to-pod traffic based on high-level policy specification. In Kubernetes Engine, these are supported using the Calico Network Plugin, created in collaboration with Tigera. Network policies help prevent an attacker from moving laterally. For example, using a network policy, a compromised front-end service can be restricted from communicating with a back-end service such as billing, giving you peace of mind through micro-segmentation of your services in the cloud. By restricting access to your services, this provides a building block to securing access and isolation in a multi-tenant microservices environment.
GCP also allows you to set up firewall rules between your Kubernetes Engine cluster nodes within your VPC network. These rules apply to egress traffic from instances and ingress traffic to instances in the network. Set up firewalls for your deployment today. Learn more about setting up network policies.
Encrypt data in transit when it leaves a physical boundary
Kubernetes Engine, as part of Google Cloud, employs several measures to ensure the authenticity, integrity and privacy of your data in transit. Kubernetes Engine protects communications between your nodes and the master through encryption, or to other services. Kubernetes Engine encrypts all data in transit at one or more network layers when data moves outside physical boundaries not controlled by Google Cloud or on behalf of Google Cloud. We use TLS to encrypt data in transit, and provide authentication, integrity and encryption using the HTTPS protocol with a certificate from a public certificate authority. Find out more in the Encryption in transit whitepaper.
Securely connect to other Google Cloud services and your GCP deployments
Private Google Access allows private RFC 1918 connectivity across VPC networks on a subnet level to other critical Google services such as Cloud Spanner, Cloud Pub/Sub, Cloud Dataproc and Cloud Storage. This allows you to securely connect to Google’s managed services without exposing your traffic to the public internet.
For connecting your on-premises infrastructure to GCP, your options include:
- Dedicated Interconnect, which offers you enterprise grade connectivity from your on-premises network to your GCP VPC
- Google Cloud Platform VPN, lets you securely connect your on-premises cluster to your Kubernetes Engine deployment
Secure your application traffic with Ingress and HTTPS
For encrypted communications between the client to the load balancer, you can specify a TLS private key and certificate to be used by the Ingress controller. You can configure Ingress by specifying a secret or a GCP SSL certificate that contains a TLS private key and certificate. Learn how to use TLS with Ingress here.Protect your deployment from DDoS attacks using our HTTP(S) and TCP load balancers
Our HTTP(S) and TCP load balancers are the result of expertise Google has gained running our services at scale. They scale up easily and offer protection against common attacks such as SYN floods, IP fragment floods, and port exhaustion. For more details, you can read the Best Practices for DDoS Protection and Mitigation on GCP whitepaper or watch the cloud networking blueprint for securing your workloads talk.
We hope that this gives you a good overview of the security features and techniques at your disposal when configuring network access to your Kubernetes Engine environment. Stay tuned next week for the next post in the container security series discussing how to harden your Kubernetes Engine environment.
