Secure egress access with DNS Policy and NetworkSets

One of the common concerns about migrating applications to Kubernetes is the control over the network traffic egressing your environment. Due to its highly dynamic architecture, Kubernetes will not tie a specific IP address to an application by default. Instead, it will lease a different IP address from an IP pool whenever the application restarts.

Suppose you use traditional network security appliances like firewalls to provide network perimeter protection. In this case, enforcing the least privilege principle by allowing only a specific application to egress traffic outside your network is impossible. In a firewall configuration, you must specify the application IP address when creating the egress rule. As it is impossible to determine the application IP address, you must allow access to the nodes’ IP addresses if you are using overlay, or to the entire IP range you use in the IP pool. By doing this, you will also allow access to any application running on that Kubernetes cluster.

Learn more: Kubernetes Network Policy: Code Example and Best Practices

A better option would be to use Kubernetes network policies, which enable you to create rules to allow ingress and egress traffic to a workload based on the labels applied to Continue reading

Technical Blog: What you can’t do with Kubernetes network policies (unless you use Calico): TLS Encryption

Kubernetes documentation clearly defines what use cases you can achieve using Kubernetes network policies and what you can’t. You are probably familiar with the scope of network policies and how to use them to secure your workload from undesirable connections. Although it is possible to cover the basics with Kubernetes native network policies, there is a list of use cases that you cannot implement by just using these policies. You can refer to the Kubernetes documentation to review the list of “What you can’t do with network policies (at least, not yet)”.

Here are some of the use cases that you cannot implement using only the native Kubernetes network policy API (transcribed from the Kubernetes documentation):

• Forcing internal cluster traffic to go through a common gateway.
• Anything TLS related.
• Node specific policies.
• Creation or management of “Policy requests” that are fulfilled by a third party.
• Default policies which are applied to all namespaces or pods.
• Advanced policy querying and reachability tooling.
• The ability to log network security events.
• The ability to explicitly deny policies.
• The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access Continue reading

What you can’t do with Kubernetes network policies (unless you use Calico)

Kubernetes documentation clearly defines what use cases you can achieve using Kubernetes network policies and what you can’t. You are probably familiar with the scope of network policies and how to use them to secure your workload from undesirable connections. Although it is possible to cover the basics with Kubernetes native network policies, there is a list of use cases that you cannot implement by just using these policies.

You can refer to the Kubernetes documentation to review the list of “What you can’t do with network policies (at least, not yet)”.

Here are some of the use cases that you cannot implement using only the native network policy API (transcribed from the Kubernetes documentation):

• Forcing internal cluster traffic to go through a common gateway.
• Anything TLS related.
• Node specific policies.
• Creation or management of “Policy requests” that are fulfilled by a third party.
• Default policies which are applied to all namespaces or pods.
• Advanced policy querying and reachability tooling.
• The ability to log network security events.
• The ability to explicitly deny policies.
• The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from Continue reading