Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/ahmetb/kubernetes-network-policy-recipes below:

ahmetb/kubernetes-network-policy-recipes: Example recipes for Kubernetes Network Policies that you can just copy paste

You can get stuff like this with Network Policies...

This repository contains various use cases of Kubernetes Network Policies and sample YAML files to leverage in your setup. If you ever wondered how to drop/restrict traffic to applications running on Kubernetes, read on.

Easiest way to try out Network Policies is to create a new Google Kubernetes Engine cluster. Applying Network Policies on your existing cluster can disrupt the networking. At the time of writing, most cloud providers do not provide built-in network policy support.

If you are not familiar with Network Policies at all, I recommend reading my Securing Kubernetes Cluster Networking article first.

NetworkPolicies operate at layer 3 or 4 of OSI model (IP and port level). They are used to control the traffic in(ingress) and out(egress) of pods.

Here are some NetworkPolicies gotcha's

• An empty selector will match everything. For example spec.podSelector: {} will apply the policy to all pods in the current namespace.

• Selectors can only select Pods that are in the same namespace as the NetworkPolicies. Eg. spec.podSelector of an ingress rule can only select pods in the same namespace the NetworkPolicy is deployed to.

• If no NetworkPolicies targets a pod, all traffic to and from the pod is allowed. In other words all traffic are allowed until a policy is applied.

• There are no deny rules in NetworkPolicies. NetworkPolicies are deny by default allow explicitly. It's the same as saying "If you're not on the list you can't get in."

• If a NetworkPolicies matches a pod but has a null rule, all traffic is blocked. Example of this is a "Deny all traffic policy".

spec:
  podSelector:
    matchLabels:
      ...
  ingress: []

• Rules are chained together. NetworkPolicy are additive. If multiple NetworkPolicies are selecting a pod, their union is evaluated and applied to that pod.

I really recommend watching my KubeCon talk on Network Policies if you want to get a good understanding of this feature. It will help you understand this repo better.

• Create a cluster

• DENY all traffic to an application
• LIMIT traffic to an application
• ALLOW all traffic to an application

• DENY all non-whitelisted traffic in the current namespace
• DENY all traffic from other namespaces (a.k.a. LIMIT access to the current namespace)
• ALLOW traffic to an application from all namespaces
• ALLOW all traffic from a namespace
• ALLOW traffic from some pods in another namespace

• ALLOW traffic from external clients

• ALLOW traffic only to certain port numbers of an application
• ALLOW traffic from apps using multiple selectors

• DENY egress traffic from an application
• DENY all non-whitelisted egress traffic in a namespace
• 🔜 LIMIT egress traffic from an application to some pods
• 🔜 ALLOW traffic only to Pods in a namespace
• LIMIT egress traffic to the cluster (DENY external egress traffic)

Created by Ahmet Alp Balkan (@ahmetb).

Copyright 2017, Google Inc. Distributed under Apache License Version 2.0 ,see LICENSE for details.

Disclaimer: This is not an official Google product.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4