Skip to main content

​
Overview

Aviatrix Distributed Cloud Firewall (DCF) for Kubernetes extends Zero Trust security to containerized workloads across AWS EKS, Azure AKS, Google GKE, and self-managed Kubernetes clusters. This integration provides identity-based security policies, secure egress control, and unified visibility for Kubernetes environments.

​
Key Capabilities

  • Identity-Based Security — Enforce firewall policies based on Kubernetes identities (namespace, pod, service) rather than ephemeral IP addresses. Policies automatically follow workloads as they scale, move, or restart.
  • Multicloud Kubernetes Security — Unified security policies across AWS EKS, Azure AKS, Google GKE, and self-managed clusters. Define security once, enforce everywhere.
  • Native Kubernetes Integration — Define firewall policies using Kubernetes Custom Resource Definitions (CRDs). Security policies are managed with the same kubectl and YAML workflows your teams already use.
  • Secure Egress Control — Prevent unauthorized outbound traffic from Kubernetes workloads. Control egress at namespace, pod, and cluster levels with domain-based filtering.
  • Advanced NAT and IP Management — Resolve IP overlap and exhaustion issues across multiple Kubernetes clusters with advanced NAT capabilities.
DCF currently enforces rules on traffic from Kubernetes clusters to destinations outside the VPC/VNet only.

​
Supported Kubernetes Distributions

  • AWS Elastic Kubernetes Service (EKS)
  • Azure Kubernetes Service (AKS)
  • Google Kubernetes Engine (GKE)
  • Self-managed and private Kubernetes clusters in cloud

​
Getting Started

To use DCF for Kubernetes:
  1. Meet the prerequisites for your cloud provider.
  2. Enable Kubernetes Resource Discovery.
  3. Onboard your Kubernetes clusters. For private clusters, see Onboarding Private Kubernetes Clusters.
  4. Enable DCF policies for Kubernetes (see below).
  5. Optionally, install CRDs for in-cluster policy management.
  6. Create SmartGroups and DCF rules.

​
Enabling DCF Policies for Kubernetes

resource "aviatrix_k8s_config" "this" {
  enable_k8s          = true
  enable_dcf_policies = true
}

​
Managing Policies with Kubernetes CRDs

DCF policies can be defined directly inside Kubernetes clusters using Custom Resource Definitions (CRDs). This allows platform teams to manage firewall policies with the same kubectl and GitOps workflows used for application deployments.

​
Installing the CRDs

Register the Aviatrix CRDs to your Kubernetes cluster using the Helm chart: 
helm install --repo https://aviatrixsystems.github.io/k8s-firewall-charts k8s-firewall k8s-firewall
Verify the CRD registration: 
kubectl get crds
Expected output includes: 
NAME                                            CREATED AT
firewallpolicies.networking.aviatrix.com        2025-11-14T07:19:03Z
webgrouppolicies.networking.aviatrix.com        2025-11-14T07:19:05Z

​
Writing a Firewall Policy

A FirewallPolicy CRD defines egress rules for pods matching a label selector. The following example permits pods with the label app: dev-pods in the dev namespace to reach www.google.com on any protocol: 
kind: FirewallPolicy
apiVersion: networking.aviatrix.com/v1alpha1
metadata:
  name: test-firewall-policy
  namespace: dev
spec:
  rules:
    - name: test
      logging: true
      selector:
        matchLabels:
          app: dev-pods
      action: permit
      protocol: any
      destinationSmartGroups:
        - name: anywhere
      webGroups:
        - name: checkip
  webGroups:
    - name: checkip
      domains:
        - "www.google.com"
  smartGroups:
    - name: anywhere
      selectors:
        - cidr: 0.0.0.0/0
Apply the policy: 
kubectl apply -f firewall-policy.yaml

​
Writing a WebGroup Policy

A WebgroupPolicy CRD defines domain-based egress filtering as a standalone resource. The following example permits pods with the label app: web-client in the default namespace to reach specific domains: 
kind: WebgroupPolicy
apiVersion: networking.aviatrix.com/v1alpha1
metadata:
  name: pod-to-web
  namespace: default
spec:
  selector:
    matchLabels:
      app: web-client
  domains:
    - "api.example.com"
    - "cdn.example.com"
Apply the policy: 
kubectl apply -f webgroup-policy.yaml

​
Verifying Policy Status

Check policy events to confirm the policy was applied successfully: 
kubectl get events -n dev
Example output for a successful FirewallPolicy: 
LAST SEEN   TYPE     REASON                    OBJECT                                MESSAGE
57m         Normal   UpdatePolicyListSuccess   firewallpolicy/test-firewall-policy   Updated policy list for firewall policy with UUID e006b5fe-bf73-46f7-93b8-d76e7325e2eb
Example output for a successful WebgroupPolicy: 
LAST SEEN   TYPE     REASON                    OBJECT                      MESSAGE
41s         Normal   CreateWebGroupSuccess     webgrouppolicy/pod-to-web   Created webgroup with name webgrouppolicy-default--pod-to-web--58c5fb5e
41s         Normal   CreateSmartGroupSuccess   webgrouppolicy/pod-to-web   Created smartgroup with name webgrouppolicy-target-default--pod-to-web--58c5fb5e
41s         Normal   CreatePolicySuccess       webgrouppolicy/pod-to-web   Updated policy webgrouppolicy-default-pod-to-web-58c5fb5e
If an event shows a Warning type or a Reason ending in Failure, check that the CRDs are installed correctly and that the Aviatrix Controller can reach the cluster.