Call Us! 1-800-383-5193
Call Us! 1-800-383-5193
Call Us! 1-800-383-5193

Need Help?

Emergency Response Time custom

Our experts have had an average response time of 11.98 minutes in June 2021 to fix urgent issues.

We will keep your servers stable, secure and fast at all times for one fixed price.

Configuring Network Policies for Applications in GKE

by | Jul 9, 2021

Configuring network policies for applications in GKE? We can help you.

As part of our Google Cloud Platform Services, we assist our customers with several Google Cloud queries.

Today, let us see how we can configure network policies.


Configuring network policies for applications in GKE

With Network policies, we can limit connections between Pods. Therefore, it provides better security and reduces the compromise radius.

In order to begin, our Support Techs suggest us to:

a) Enable the Kubernetes Engine API:

  1. In Google Cloud Console, we go to the Kubernetes Engine page.
  2. Here, we create or select a project.
  3. Then we wait for the API and its services to enable.

b) Install the following command-line tools that may come in handy:

  1. gcloud, to create and delete Kubernetes Engine clusters.
  2. kubectl, to manage Kubernetes.

With gcloud we can install kubectl:

gcloud components install kubectl


Set defaults for the gcloud command-line tool

Instead of typing the project ID and Compute Engine zone options in the gcloud command-line tool, we can set the defaults:

gcloud config set project project-id
gcloud config set compute/zone compute-zone


Create a GKE cluster

We can create a container cluster with network policy enforcement using:

gcloud container clusters create test --enable-network-policy


Restrict incoming traffic to Pods

The NetworkPolicy resources of Kubernetes will let us configure network access policies for the Pods.

Initially, we run a web server application with the label app=hello and expose it internally in the cluster:

kubectl run hello-web --labels app=hello \ --port 8080 --expose

Next, to allow traffic to the hello-web Pods from only the app=foo Pods we configure a NetworkPolicy.

Any other incoming traffic from Pods that do not have this label will be blocked.

The following manifest selects Pods with label app=hello and specifies an Ingress policy:

kind: NetworkPolicy
name: hello-allow-from-foo
- Ingress
app: hello
- from:
- podSelector:
app: foo

To apply this policy to the cluster, we run:

kubectl apply -f hello-allow-from-foo.yaml


Validate the Ingress policy

First, we run a temporary Pod with the label app=foo and get a shell in the Pod:

kubectl run -l app=foo --image=alpine --restart=Never --rm -i -t test-1

Then we make a request to the hello-web:8080 endpoint to verify that it allows the incoming traffic:

/ # wget -qO- --timeout=2 http://hello-web:8080
Hello, world!
Version: 1.0.0
Hostname: hello-web-2258067535-vbx6z
/ # exit

Now, the traffic from Pod app=foo to the app=hello Pods is enabled.

Next, to get the shell inside the pod, we run a temporary Pod with a different label (app=other):

kubectl run -l app=other --image=alpine --restart=Never --rm -i -t test-1


Restrict outgoing traffic from the Pods

Just like we can restrict incoming traffic we can restrict outgoing traffic as well.

However, to be able to query internal hostnames we must allow DNS resolution in the egress network policies.

To do this, we deploy a NetworkPolicy controlling outbound traffic from Pods with the label app=foo. We will also allow traffic only to Pods with the label app=hello, as well as the DNS traffic.

The following manifest specifies a network policy controlling the egress traffic from Pods with label app=foo with two destinations:

  • Pods in the same namespace with the label app=hello.
  • Cluster Pods or external endpoints on port 53.
kind: NetworkPolicy
name: foo-allow-to-hello
- Egress
app: foo
- to:
- podSelector:
app: hello
- ports:
- port: 53
protocol: TCP
- port: 53
protocol: UDP

We run the below command to apply this policy to the cluster:

kubectl apply -f foo-allow-to-hello.yaml


Validate the egress policy

Initially, we deploy a new web application called hello-web-2 and expose it internally in the cluster:

kubectl run hello-web-2 --labels app=hello-2 \ --port 8080 --expose

Then, we open a shell inside the container and run a temporary Pod with the label app=foo:

kubectl run -l app=foo --image=alpine --rm -i -t --restart=Never test-3

We need to validate that the Pod can establish connections to hello-web:8080:

/ # wget -qO- --timeout=2 http://hello-web:8080
Hello, world!
Version: 1.0.0
Hostname: hello-web-2258067535-vbx6z

Then we validate that the Pod cannot establish connections to hello-web-2:8080:

/ # wget -qO- --timeout=2 http://hello-web-2:8080
wget: download timed out

In addition, we validate that the Pod cannot establish connections to external websites and exit:

/ # wget -qO- --timeout=2
wget: download timed out
/ # exit


Clean up

We can avoid incurring charges to your Google Cloud account for using these resources. To do so, we need to either delete the project that contains the resources or keep the project and delete the individual resources.

If we delete the container cluster, it will delete the resources that make up the container cluster:

gcloud container clusters delete test

[Need help with the configuration? We’d be happy to assist]



In short, we saw how our Support Techs configure network policies for applications in GKE.


Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.


var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center


Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]


Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid


Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie


These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.