Skip to main content
When complete, every MCP server Obot deploys on EKS will automatically receive a workload-scoped containment policy. Egress domain declarations are managed through Obot’s server catalog. The Aviatrix network policy controller translates those declarations into FirewallPolicy CRDs, enforced at the VPC boundary by the Aviatrix spoke gateway. When a server is removed, its policy is removed with it. For the business case and architecture overview, see MCP Server Security Through Containment Architecture. For the complete Terraform reference implementation, see the obot-mcp-egress-aws blueprint. Reference architecture: namespace layout, NPC controller, FirewallPolicy CRDs, and Aviatrix three-tier enforcement

Prerequisites

Procedure

1

Deploy an Aviatrix spoke gateway in the cluster VPC

An Aviatrix spoke gateway in the same VPC as your Kubernetes cluster is the enforcement point where the Aviatrix controller applies containment policy to MCP server egress traffic.
  1. In CoPilot, navigate to Cloud Fabric > Gateways > Spoke Gateways and click + Spoke Gateway.
  2. Provide the following details:
  3. In the Instances section, select a subnet in the cluster VPC for the gateway instance.
  4. Click Save.
Wait for the gateway status to show Up before continuing. You can monitor progress at CoPilot > Monitor > Notifications > Tasks.
2

Confirm network topology

The spoke gateway must be deployed in the public subnet, with the EKS cluster in the private subnet of the same VPC. Pod egress routes via the node subnet route table to the gateway. Confirm your VPC CIDR, subnet assignments, and gateway placement before continuing.EKS VPC topology: private subnets with EKS cluster, public subnet with Aviatrix spoke gateway, egress routing path
3

Install the Aviatrix Kubernetes Firewall Helm chart

The Aviatrix Kubernetes Firewall Helm chart deploys the in-cluster components that allow the Aviatrix controller to reconcile and enforce containment policies on the cluster.Run the following command against the target cluster, replacing <chart-version> with the current chart version from the Aviatrix k8s-firewall-charts repository:
4

Verify Aviatrix CRD installation

The Helm chart installs two Aviatrix CRDs on the cluster. Verify both are present before continuing:
Expected output:
If either CRD is missing, re-run the Helm installation and check the output for errors.
5

Onboard the Kubernetes cluster to Aviatrix DCF

  1. Navigate to Cloud Resources > Cloud Assets > Kubernetes Clusters.
  2. Click Onboard next to the target cluster.
  3. Choose the appropriate access method for your cloud provider:
    • AWS (EKS): Select Terraform or Command Line, apply the generated access entry and RBAC configuration, check the confirmation box, then click Onboard.
    • Azure (AKS): Select Permissions on Cloud Account if the Aviatrix service principal has the required permissions, or Kubeconfig File to upload a kubeconfig. Click Onboard.
  4. Wait for the cluster status to show Yes (green) on the Kubernetes Clusters tab.
EKS clusters require a view-nodes ClusterRole so the Controller can discover node metadata. The CoPilot onboarding dialog generates the required YAML automatically — apply it before clicking Onboard.
6

Configure V1 DCF policies and default deny

Before enabling default deny, configure V1 infrastructure permit rules so the cluster continues to function. These rules allow node-level traffic (ECR image pulls, AWS platform services) that must be permitted independently of per-pod MCP containment policies.Create SmartGroupsNavigate to Security > Distributed Cloud Firewall > Groups > SmartGroups and create:eks-vpc: source for infrastructure rules
  • Match type: CIDR
  • CIDR: the EKS VPC CIDR (for example, 10.0.0.0/16)
obot-system: Obot orchestration pods
  • Match type: Kubernetes
  • Namespace: the Obot system namespace (for example, obot-system)
Create WebGroupsNavigate to Security > Distributed Cloud Firewall > Groups > WebGroups and create:eks-infra-egress: EKS infrastructure domains required by all nodes and podsobot-pod-egress: domains required by Obot orchestration pods
  • charts.obot.ai, api.anthropic.com, github.com, *.github.com, raw.githubusercontent.com, *.githubusercontent.com
Create V1 policy rulesNavigate to Security > Distributed Cloud Firewall > Policy and create the following rules in priority order:Enable default denyNavigate to Security > Distributed Cloud Firewall > Policy > Default Action and set the default action to Deny with Logging enabled.
Default deny must be set at POST_RULES level, not as a V1 policy rule. A V1 deny evaluates before the Kubernetes CRD enforcement block (K8S_POLICY_LIST). Setting deny in V1 would block all FirewallPolicy PERMIT rules generated by the network policy controller.
7

Configure Obot with the Aviatrix network policy provider

Add the Aviatrix network policy provider configuration to your Obot Helm release. Obot’s PostStart hook reads these values and deploys the aviatrix-network-policy-controller chart into the cluster automatically.
Replace <npc-version> with the current chart version from charts.obot.ai.OBOT_SERVER_MCPDEFAULT_DENY_ALL_EGRESS=true ensures any MCP server deployed without declared egress domains starts with zero outbound access. Without this setting, servers with no egress declaration inherit the environment’s default posture.After the upgrade, verify the network policy controller is running:
On EKS, Kubernetes label-based SmartGroups (used by FirewallPolicy selectors) may register as Partial in the Aviatrix controller due to a current limitation in the asset discovery watcher. The FirewallPolicy CRDs are created and the default deny rule provides the baseline block. If strict per-pod permit enforcement is required before this limitation is resolved, contact Aviatrix support for the CIDR-based enforcement workaround.
8

Declare egress destinations per MCP server

Egress destinations are declared in the Obot server catalog, not in Kubernetes manifests. Each MCP server’s allowed domains are part of its configuration in Obot.Via the Obot admin UI:When adding or editing an MCP server in the Obot admin catalog, set the Egress Domains field to a list of permitted destinations, for example api.github.com and *.githubusercontent.com.Via the Obot API:
Domain rules:
  • Bare hostname or leading wildcard only: api.example.com or *.example.com
  • No protocols, paths, ports, or IP addresses
  • localhost, *.svc, and bare * are rejected
  • Empty egressDomains with OBOT_SERVER_MCPDEFAULT_DENY_ALL_EGRESS=true results in zero outbound access for that server
For the full egressDomains specification, see the Obot MCP server egress control documentation. Egress enforcement applies to HTTPS on TCP port 443 only; connections on other ports are blocked regardless of domain declarations.When Obot deploys the server, the network policy controller generates a FirewallPolicy CRD targeting that server’s pods. Inspect generated policies:
Generated policy names follow the pattern obot-<mnp-id>-fw. Pod labels use an internal server ID (app: <server-id>, for example app: ms16mfzb), not the human-readable server name. This is expected.
9

Verify containment

  1. Deploy an MCP server through Obot and confirm a FirewallPolicy was generated:
  2. Check that the policy was applied successfully:
    A successful apply produces an event with Reason: UpdatePolicyListSuccess.
  3. In CoPilot, navigate to Security > Distributed Cloud Firewall and select the cluster. Confirm the server’s containment policy appears with the correct egress allow-list.
  4. To confirm egress blocking is active, attempt a connection from an MCP server pod to a destination not in its declared domains and verify it is denied. In CoPilot per-connection logs, a denied connection appears with Action: Deny. If no entry appears within a few seconds, verify that the spoke gateway is in the egress data path for the cluster’s node subnet.