Webmobix Logo

Team

Unlocking DevOps Agility: How We Automated Firewall Rules with a Kubernetes Operator

Is your DevOps team struggling to keep up with the demands of managing firewall rules in your Kubernetes environment? Imagine a world where developers can self-service their network configurations with ease, while security teams maintain complete control. At Webmobix Solutions AG, we helped a client achieve this vision by developing a custom Kubernetes operator that streamlines Illumio firewall rule management. In this post, we’ll share the journey of how we built this solution and the dramatic impact it had on our client’s DevOps efficiency.

The Challenge: Drowning in Jira Tickets

Before our intervention, our client’s developers were trapped in a frustrating cycle of Jira tickets and endless waiting. Every firewall change, whether for production or a simple development environment, required navigating a cumbersome service desk form.

This form, with its cramped table and embedded fields, was a usability nightmare. Important details often ended up crammed into the description field, creating a chaotic mess of unstructured data. This lack of standardization made it impossible for the security team to automate any part of the process.

The pain points were clear:

The result? A bottleneck that stifled innovation and slowed down the entire development lifecycle. Developers were frustrated, security personnel were overwhelmed, and the business suffered from the delays. It was clear that a new approach was needed - one that empowered developers, streamlined the process, and enhanced security.

The Solution: A Custom Kubernetes Operator

To break free from the Jira ticket quagmire, we envisioned a solution that put the power back into the hands of developers while maintaining robust security controls. Our answer? A custom-built Kubernetes operator designed to seamlessly integrate with Illumio’s security platform.

Here’s how it works:

Building the Solution: Implementation Deep Dive

Turning our vision into reality required careful technical choices and innovative problem-solving. Here’s how we brought the Illumio Operator to life using modern cloud-native technologies.

Foundation: Making Technology Choices

We built our solution on proven, enterprise-ready technologies:

Elegant Validation Architecture

One of our key design decisions was implementing a flexible and extensible validation system. At its heart is a simple yet powerful interface that all validation rules must implement:

type Rule interface {
    Evaluate() (Response, error)
}

This interface allows us to create a pipeline of validation rules that can be easily composed and maintained. The pipeline runner itself is remarkably straightforward:

package whitelisting

type Pipeline struct {
    Rules []Rule
}

func NewPipeline() *Pipeline {
    return &Pipeline{}
}

func (p *Pipeline) AddRule(rule Rule) *Pipeline {
    p.Rules = append(p.Rules, rule)
    return p
}

func (p *Pipeline) Run() (Response, error) {
    for _, rule := range p.Rules {
        resp, _ := rule.Evaluate()
        if resp.Allowed == false {
            return resp, nil
        }
    }
    return Response{
        Reason:  "AllRulesOK",
        Message: "",
        Allowed: true,
    }, nil
}

Real-World Rule Implementation

Here’s a concrete example of how we implement and use a validation rule for ports:

type PortRule struct {
    ports []v1alpha1.RuleSpecToPort
}

func NewPortRule(ports []v1alpha1.RuleSpecToPort) *PortRule {
    return &PortRule{
        ports: ports,
    }
}

func (s *PortRule) Evaluate() (Response, error) {
    // check that not more than 5 ports are requested
    numberOfPorts := CountAllPorts(s.ports)
    if numberOfPorts > 5 {
        return Response{
            Reason:  "TooManyPortsFailure",
            Message: "Too many ports requested.",
            Allowed: false,
        }, nil
    }
    
    // check that no port is below 100
    hasPortBelow100 := CheckForPortLowerThan100(s.ports)
    if hasPortBelow100 {
        return Response{
            Reason:  "PortBelow100Failure",
            Message: "No port below 100.",
            Allowed: false,
        }, nil
    }
    
    return Response{
        Reason:  "PortFilterOK",
        Message: "",
        Allowed: true,
    }, nil
}

Using the validation pipeline is as simple as:

ruleCheckPipeline := whitelisting.NewPipeline()
ruleCheckPipeline.AddRule(whitelisting.NewPortRule(rule.Spec.To.Ports))
resp, err := ruleCheckPipeline.Run()

Comprehensive Error Handling

Our operator implements thorough error handling and status reporting:

Handling API Timeouts

One significant challenge we encountered was the Illumio API response times exceeding the default 10-second webhook timeout. This taught us valuable lessons about building resilient operators that interact with external services, leading to improved timeout configurations and error handling strategies.

Using the Operator: From Development to Production

After successfully implementing and testing the operator, we rolled it out gradually across all environments, collecting valuable user feedback along the way. Let’s explore how developers can leverage this solution to manage their firewall rules effectively.

Defining Network Rules

The operator introduces a straightforward Custom Resource Definition (CRD) that makes firewall rule management intuitive and GitOps-friendly. Here are some common use cases:

Internal Namespace Communication

To allow services in your namespace to communicate with another namespace:

apiVersion: illumio/v1alpha1
kind: Rule
metadata:
  name: namespace-rule
spec:
  to:
    namespace: namespace
  description: From your own namespace to another namespace

This simple declaration automatically configures Illumio to permit connections from the current namespace to the specified target namespace.

External Workload Access

For connecting to specific workloads outside the Kubernetes cluster:

apiVersion: illumio/v1alpha1
kind: Rule
metadata:
  name: rule-operating-workload
spec:
   to:
    workload: tzrh-s7911.wdom.dmz
    ports:
    - port: 8080
      to_port: 8082     # Optional, port range (from port to to_port)
      protocol: tcp     # Optional (default: tcp)
   description: Connection to a server outside of OpenShift

Best Practices and Workflows

We’ve developed several best practices based on real-world usage:

  1. GitOps Integration

    • Store firewall rules alongside your application code
    • Apply rules automatically during deployment
    • Leverage source control for rule versioning and auditing

  2. Service Abstraction

    • Use Illumio IPLists to abstract common services
    • Define reusable rules for shared resources like Bitbucket
    • Maintain consistent access patterns across environments

  3. Rule Organization

    • Group rules logically by service or function
    • Use clear, descriptive names for rules
    • Include meaningful descriptions for easier maintenance

Deployment Strategy

Our gradual rollout approach proved successful in ensuring a smooth transition:

The operator’s validation pipeline helped catch issues early, while the comprehensive logging and status reporting made troubleshooting straightforward.

Next Steps

Are you ready to streamline your firewall management and empower your developers? Contact Webmobix Solutions AG to learn how we can help implement this solution in your environment. Our team of experts can help you:

Visit our website or reach out to our team to start your journey toward more efficient and secure network management.