⛈️ Network Policies bringing you or your production down?
Beat them in the hands-on, no-setup Network Policies lab

Blog
  • Zero-trust
  • Kubernetes
  • Network Policy
  • Lab

Automate Kubernetes Network Policies with Otterize: hands-on lab for dynamic security

Let's talk about the challenges of Kubernetes Network Policies as you scale and progress through your development lifecycle journey. Even better, experiment with how Otterize overcomes these challenges in a practical lab!

Written By
Nic Vermandé
Published Date
Sep 17 2024
Read Time
7 minutes





Try the lab now!



If you've ever worked with Network Policies in Kubernetes environments supporting production workloads or scalable architecture patterns, you understand that maintaining robust security can feel like trying to hit a moving target. As applications grow and change, these policies often struggle to keep pace, leaving potential security gaps or causing unnecessary restrictions.

The Network Policy conundrum

Network Policies in Kubernetes are powerful tools for controlling pod-to-pod communication. However, they come with a significant drawback: they're static by nature. As new code is released and application architectures evolve, Network Policies don't automatically update to reflect these changes. This can lead to several issues:

  • Outdated policies that no longer accurately represent the required communication patterns

  • Overly permissive policies that create security vulnerabilities

  • Overly restrictive policies that break application functionality

Manually updating these policies with each code release is time-consuming and error-prone, often leading to frustration for both developers and security teams.

The responsibility dilemma

Who should be responsible for crafting Network Policies? Many argue that it's more of an art than an exact science. However, a systematic approach could be applied, provided that application flows and internal API architecture are well-documented and up-to-date. This is where the challenge begins, as it involves multiple teams:

  • The team responsible for application development

  • The team overseeing the platform supporting these applications during their lifecycle stages

To address this challenge, we need to solve 3 key problems:

  1. How to deploy and maintain policies that reflect the current application architecture

  2. How to evolve policies without causing application disruption or security breaches

  3. How to share responsibility between different teams

    Solving the policy puzzle

    The first problem can be approached in two ways:

    • Developers can define what the application requires to function properly, similar to an iOS application's info.plist file

    • Requirements can be automatically generated by observing traffic flows at runtime within the development sandbox



      For example, consider this XML excerpt from an iOS info.plist file:

<key>UIRequiredDeviceCapabilities</key>
<array>
    <string>armv7</string>
    <string>gps</string>
    <string>location-services</string>
    <string>wifi</string>
    <string>still-camera</string>
    <string>microphone</string>
</array>


This concept can be easily transferred to Kubernetes if we consider every capability to be represented as discrete microservices.

Otterize IBAC and ClientIntents to the rescue


This is where Otterize comes in with Identity-Based Access Control (IBAC) and ClientIntents. Developers can co-locate their requirements with the code or include them in Infrastructure as Code (IaC) repositories using skeletons crafted by the platform team. To continue with this analogy, Otterize can dynamically generate these requirements by monitoring any application call and looking at DNS traffic, TCP traffic, or relying on eBPF to get deeper application-layer visibility.

Try it by yourself with the self-paced lab!


We've created an interactive lab to help you experience firsthand how Otterize can simplify your Kubernetes security workflow. In this hands-on lab, you will:

  • Deploy a "Shifumi" (rock-paper-scissors) game application as a Rube Goldberg machine implementation composed of multiple microservices, including Go workers and Kafka.

  • Explore how the app uses Kafka for message streaming

  • Learn to secure the application components using Otterize

  • Automate the creation and management of Kubernetes Network Policies as the application evolves with additional game statistics

This lab is perfect for developers, DevOps engineers, and anyone interested in practical Kubernetes security. No prior experience with Otterize is required!

Launch the self-paced lab now and take the first step towards effortless, automated network policy management!

Evolving policies and sharing responsibility


To address the second and third problems, Otterize leverages GitOps workflows alongside the ability to detect flow patterns at runtime across dev, staging, and production environments. This approach challenges the static mindset often encountered in production environments.

A platform engineer recently stated, "Our application deployment process in production is static; no one can make any changes, so there's no need to monitor the traffic since nothing will ever be modified." However, this statement ignores zero-trust principles and modern security paradigms.

The zero-trust imperative


The industry has moved away from the client/server model and "zone-based" security. Every application component is now a process, ideally sandboxed within a container, with its own network stack. Security and anomaly detection must be brought closer to that unit of compute.

Even if flows are not supposed to change, nothing guarantees that a bad actor or unforeseen event won't trigger unexpected traffic. Otterize can instantly detect these calls and trigger various signals, such as ChatOps messages or raise a fresh pull request on the IaC or application code repository. In cases where a legitimate call has been overlooked by the team, the pull request can be merged after approval from the relevant person, ensuring that security policies evolve alongside the application.

Advancing Kubernetes security: from Network Policies to holistic protection


By adopting this dynamic, zero-trust approach to Network Policies, organizations can maintain robust security while allowing for the natural evolution of their applications and infrastructure. This method bridges the gap between development agility and security requirements, fostering a more collaborative and secure Kubernetes environment.


However, adopting a zero-trust approach doesn't stop at network access. While securing the "where" (network) is crucial, we also need to address the "who" and "what" aspects of security. This is where Otterize truly shines, offering a comprehensive solution that seamlessly integrates with your workloads.


Otterize extends its capabilities beyond network policies, covering identity and application IAM layers by integrating with solutions such as SPIFFE/SPIRE for IAM and mTLS. It then projects these identities into other access management primitives, including Kafka and backend databases like PostgreSQL or MySQL. The unifying factor across all these integrations is the ClientIntent and IBAC (Intent-Based Access Control) approach, maintaining the same philosophy of simplicity and automation.


What sets Otterize apart is its ability to continuously monitor application flows and map them to pre-defined compliance rules for regulated environments such as PCI DSS or HIPAA. This proactive approach allows Otterize to quickly identify non-conformities and trigger automated workflows for remediation. These workflows can range from applying specific ClientIntents to initiating a security "war room" (a.k.a incident response team) to address critical issues.


By leveraging Otterize's full suite of capabilities, you can create a holistic zero-trust environment that covers all aspects of your application security. From network policies to identity management and application-level access control, Otterize provides a unified, intent-based approach that simplifies security management while enhancing your overall security posture.

Stay connected and learn more


If you found this article helpful, we'd love to hear from you! Here are some ways to stay connected and dive deeper into Otterize:

🏠 Join our community


Stay ahead of the curve by joining our growing Slack community. Get the latest Otterize updates and discuss real-world use cases with peers.

🌐 Explore our resources


Take a sneak peek at our datasheets:

Or continue your exploration journey with our blogs and tutorials!


Don't be a stranger – your insights and questions are valuable to our community!

Like this article?

Sign up for newsletter updates

By subscribing you agree to with our Privacy Policy and to receive updates from us.
Share article
Blog & Content

Read things that Otis, our sweet mascot, wrote. Oh, and also the rest of the team. But they aren't otters so whatevs.

    Blog
    Oct 31 2024
    Kubernetes Liveness Probe Failed: Connection Refused

      Blog
      Oct 24 2024
      DNS Resolution Failure in Kubernetes? Network Policies Might Be the Culprit!

        Blog
        Oct 17 2024
        Prometheus Can't Reach Your App? Network Policies Might Be to Blame!