Source: Exploring container security: Protecting and defending your Kubernetes Engine network from Google Cloud Platform
By Manjot Pahwa, Product Manager, Cloud Networking; Ahmet Balkan, Developer Experience Engineer and Bowei Du, Software 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:
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.
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.
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.
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.
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.
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.
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:
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.
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.