Containers

Enhance Amazon EKS network security posture with DNS and admin network policies

Amazon Web Services (AWS) announced the availability of DNS-based and Admin network policies for Amazon Elastic Kubernetes Service (EKS) Auto mode and Admin network policies for both EKS Auto mode and EKS on Amazon Elastic Compute Cloud (EC2), providing enhanced capabilities to secure network traffic both within your clusters and to external endpoints. These new policy types enable you to implement stable, domain-based access controls for external services while centrally managing security policies across multiple namespaces, reducing operational complexity and strengthening your overall security posture. In this post, we explore practical use cases that demonstrate how these policies solve real-world challenges and remove the need to rely on third-party software across different deployment scenarios, from securing access to external services to hybrid cloud integration and multi-tenant environments.

Application modernization drives demand for sophisticated network security that simplifies operations at scale. Modern containerized applications require granular control over external endpoint access, enabling teams to precisely manage which cluster-external services (such as AWS services, on-premises systems, and third-party APIs) their workloads can reach. Teams want to move beyond IP-based filtering to DNS-based access control, leveraging stable domain names rather than constantly changing IP addresses for more predictable and maintainable security policies. Organizations also need centralized policy management capabilities that enforce consistent security standards across multiple namespaces and workloads, ensuring uniform protection without requiring individual teams to implement policies independently. As these environments grow, there’s an increasing focus on operational simplicity, reducing the administrative overhead of managing network-level security while maintaining strong defensive postures that scale effectively with business growth.

Amazon EKS enhanced network policies

Admin network policies

Admin network policies provide centralized, cluster-wide network access control that spans multiple namespaces. The ClusterNetworkPolicy represents the EKS implementation of the upstream AdminNetworkPolicy and BaselineAdminNetworkPolicy, combining both into a single Custom Resource Definition (CRD). Admin policies are a cluster-scoped resource and are applied to all namespaces in the cluster. Key capabilities include:

  • Cross-namespace control: Define policies that apply to workloads across multiple namespaces based on label selectors.
  • Hierarchical policy management: Implement organization-wide security standards that cannot be overridden by individual namespace policies.
  • Tiered enforcement: Admin policies operate in two tiers – Admin tier for mandatory security controls and Baseline tier for default policies that can be overridden by namespace-level policies.

DNS-based network policies

DNS-based network policies allow you to control egress traffic from your pods using Fully Qualified Domain Names (FQDNs) and domain patterns, rather than IP addresses. The new ApplicationNetworkPolicy CRD is the EKS extension of the upstream existing NetworkPolicy resource. This CRD is necessary for EKS to allow customers to specify Network Layer FQDN rules and in the future Application Layer (Layer 7) rules. This approach provides several key benefits:

  • Stability and predictability: Domain names remain consistent even when underlying IP addresses change, eliminating the need to constantly update network policies as infrastructure evolves.
  • Simplified management: Instead of maintaining complex IP allowlists, you can use intuitive domain-based rules like *.amazonaws.com or api.example.com.
  • Hybrid cloud support: Seamlessly control access to both AWS services and on-premises systems using the same DNS-based approach.

You can find details on these enhanced network policies in the launch blog post and the Amazon EKS documentation.

Implementation across EKS deployment models

EKS Auto (v.1.29+) existing and new clusters support both Admin and DNS-based network policies. The managed networking stack automatically handles policy enforcement. EC2-based EKS clusters support Admin network policies, implemented through the Amazon VPC CNI plugin. To enable, you’ll need to update your VPC CNI to version 1.21.1 or later, enable network policy support by configuring the VPC CNI with the appropriate network policy capabilities, and then deploy your policies using standard Kubernetes manifests and the specific CRDs.

Use cases

1. Enforcing cluster-level security with Admin network policies

Organizations often need to enforce cluster-level network policies that prevent pods from accessing certain destinations, for example the EC2 Instance Metadata Service (IMDS), which can expose sensitive IAM credentials and instance information. Admin network policies provide the perfect solution by enforcing this security control cluster-wide, regardless of what namespace-level policies developers might create. For example, consider your security team needs to ensure that no workloads in the cluster can access the EC2 metadata service at 169.254.169.254/32, which could expose IAM role credentials. This is a mandatory security requirement that cannot be overridden by individual development teams. Here’s an Admin network policy example that demonstrates this:

#Deny traffic to IMDS at the cluster level
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: block-instance-metadata-service
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces: {}  # applies to all namespaces
  egress:
    - name: deny-metadata-service
      action: Deny
      to:
        - networks:
            - cidr: "169.254.169.254/32"

The admin tier policy cannot be overridden by namespace-level policies that developers create, and applies to all namespaces automatically, including future namespaces. The key benefit is that platform teams can enforce critical security requirements without relying on developers to implement them correctly in each namespace. Even if a developer creates a permissive namespace-scoped policy, the admin policy’s deny action takes precedence.

2. Securing access to AWS services in multi-tenant environments

Organizations running multi-tenant Kubernetes environments face a common challenge: managing which workloads can access which AWS services while maintaining operational simplicity and security. In traditional approaches, teams might use Security Groups for Pods (SGPP) or IP-based network policies to control access to AWS services like Amazon RDS, Amazon S3, or Amazon DynamoDB. However, these approaches have limitations. IP-based policies require constant maintenance as AWS service endpoints change, and SGPP adds operational complexity by requiring additional Kubernetes resources and careful management of VPC security group associations. DNS-based network policies combined with Admin policies provide an optimized solution to this challenge. Instead of tracking and allowlisting specific IP addresses for AWS service endpoints, you can use stable, predictable domain names that AWS maintains. When AWS updates the underlying infrastructure or adds new endpoints, your policies remain valid without any modifications. For example, consider a scenario where you’re running multiple payment applications across different namespaces in a low security zone, all requiring access to Amazon Simple Storage Service (S3). Here is an example of the DNS-based network policy you can apply:

#Allow traffic to S3 for low security tier applications
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: access-to-s3
  namespace: default
spec:
  podSelector:
    matchLabels:
      security-tier: low
  policyTypes:
    - Egress
  egress:
    - name: allow-access-to-S3
      action: Accept
      to:
        - domainNames:
          - "*.s3.us-east-1.amazonaws.com"

You can also implement a more granular DNS-based policy per namespace, or application. Let’s consider a checkout-service which needs access to Amazon DynamoDB. Here is an example of the DNS-based network policy:

#Allow traffic to DynamoDB for the 
#checkout-service in the cart-services namespace
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: access-to-DynamoDB
  namespace: cart-services
spec:
  podSelector:
    matchLabels:
      app: checkout-service
  policyTypes:
    - Egress
  egress:
    - name: allow-dynamodb-access
      action: Accept
      to:
        - domainNames:
          - "*.dynamodb.us-east-1.amazonaws.com"

3. Hybrid cloud integration

Organizations with hybrid architectures face unique challenges when managing network security across cloud and on-premises environments. Traditional IP-based network policies become particularly cumbersome in these scenarios because on-premises infrastructure often uses dynamic IP allocation, load balancers with rotating addresses, or private IP ranges that may overlap with cloud networks.

DNS-based network policies solve these challenges by abstracting away the underlying network complexity. When your EKS workloads need to access on-premises databases, internal APIs, or legacy systems, DNS-based policies provide the flexibility to manage these connections without constantly updating policies as infrastructure evolves. For example, if your organization is gradually migrating services from on-premises data centers to AWS, the DNS-based approach allows you to maintain consistent security policies throughout the migration. As you move a database from db.internal.company.com hosted on-premises to an Amazon RDS instance with the same DNS name, your network policies remain valid. You simply update DNS records rather than modifying network policies across all your clusters.

This approach also provides operational benefits for organizations managing multiple data centers or hybrid cloud deployments across multiple AWS Regions. Admin policies enable you to centrally define cluster-wide access to on-premises resources, while DNS-based filtering ensures that access remains stable even as your infrastructure team makes changes to load balancers, adds new servers, or reconfigures network topology. The policies are infrastructure-agnostic, focusing on the logical service names rather than the physical network addresses. Let’s consider your EKS workloads need to access on-premises databases and internal APIs across multiple data centers:

#Allow namespaces labeled with "hybrid" to access on-premises apps
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: on-premises-access
spec:
  tier: admin
  priority: 200
  subject:
    namespaces:
      namespaceSelector:
        matchLabels:
          data-access: hybrid
  egress:
    - name: allow-datacenter-access
      action: Accept
      to:
        - domainNames:
            - "*.datacenter.company.com"
            - "*.corp.company.com"
      ports:
        - protocol: TCP
          port: 443

This policy allows any namespace labeled with data-access: hybrid to access your internal services using domain patterns. While this example demonstrates centralized control using Admin policies to manage access across multiple namespaces, you can also achieve pod-level granularity within individual namespaces using DNS-based network policies. For scenarios where you need fine-grained control over which specific pods (rather than all pods in a namespace) can access on-premises resources, you can create an ApplicationNetworkPolicy in each namespace with a podSelector that targets pods with specific labels, such as access-type: hybrid. This approach provides maximum flexibility for application teams to define their own access controls while still benefiting from DNS-based filtering for stable, maintainable policies.

Implementation best practices

Building baseline security with deny-by-default rules

Establishing a strong security foundation begins with implementing a deny-by-default posture using Admin network policies. This approach ensures that all traffic to specific destinations is blocked unless explicitly allowed, significantly reducing your attack surface and preventing unauthorized access to external resources. This deny-by-default strategy forces teams to explicitly define and justify their external connectivity requirements, creating a more secure and auditable environment. Once your baseline deny policies are in place, you can then layer on specific allow rules through both Admin and namespace-scoped policies to enable legitimate business functionality. Here’s an example of this policy:

Using label-based segmentation

Label-based segmentation provides a powerful mechanism for creating logical security boundaries that align with your organizational structure and security requirements. Rather than managing policies for individual namespaces, you can use Kubernetes labels to group namespaces by security tier, environment, compliance requirements, or business function. For example, you might label namespaces handling sensitive data with security-tier: high and apply more restrictive network policies to those namespaces, while development environments labeled with security-tier: low receive more permissive policies. This approach scales effectively as your cluster grows because new namespaces automatically inherit the appropriate security controls simply by applying the correct labels.

Label-based segmentation also allows you to implement role-based access patterns, where different teams or applications receive network access based on their functional requirements rather than their physical namespace location. This abstraction layer makes your security policies more maintainable as your infrastructure evolves. Here’s an example of the policy using labels:

spec:
  subject:
    namespaces:
      namespaceSelector:
        matchLabels:
          security-tier: high

Combining DNS policies with traditional network policies

DNS-based network policies, Admin network policies, and traditional Kubernetes network policies are designed to work together, enabling a comprehensive defense-in-depth security strategy. Each policy type serves a distinct purpose in your overall security architecture.

  • Traditional Kubernetes network policies excel at controlling pod-to-pod communication within your cluster using IP addresses and CIDR blocks, allowing you to implement micro-segmentation and zero-trust networking between your application components.
  • Admin network policies provide the organizational governance layer, enabling security teams to enforce cluster-wide standards that span multiple namespaces and cannot be overridden by individual development teams. Admin policies can use either IP-based rules (CIDR blocks) or DNS-based rules (FQDNs), giving administrators flexibility to enforce security controls using whichever approach best fits their requirements. For example, you might use IP-based Admin policies to block access to the EC2 metadata service (169.254.169.254/32), while using DNS-based Admin policies to control access to specific AWS service endpoints (*.s3.amazonaws.com).
  • DNS-based network policies are still network policies. They control network traffic just like traditional policies, but they allow you to specify egress rules using Fully Qualified Domain Names (FQDNs) and domain patterns instead of IP addresses. This makes it intuitive and stable to manage connectivity to external services like third-party APIs, SaaS platforms, and AWS services, since domain names remain consistent even when underlying IP addresses change.

By combining these policy types, you create multiple layers of security controls that protect your workloads from different threat vectors while maintaining operational flexibility for your development teams.

Monitoring and audit

Effective network security requires continuous monitoring and auditing of policy decisions to ensure compliance with your security requirements and to detect potential security incidents. Enabling policy logging provides visibility into which network connections are being allowed or denied, helping you validate that your policies are working as intended and identify any gaps in your security posture. Policy logs can be integrated with your existing security information and event management (SIEM) systems or AWS CloudWatch for centralized monitoring and alerting. Regular auditing of policy logs helps you identify unusual network access patterns that might indicate compromised workloads or misconfigurations. Additionally, monitoring policy decisions during application deployments helps you quickly identify and resolve connectivity issues caused by overly restrictive policies, reducing the time to resolution for application problems. By maintaining comprehensive logs of network policy decisions, you also create an audit trail that demonstrates compliance with regulatory requirements and internal security standards.

Considerations

Understanding policy evaluation order

Network policies in Amazon EKS are evaluated in a specific order to ensure predictable and secure traffic management. Understanding this evaluation flow is critical for designing effective security policies.

  • Admin tier policies (evaluated first): All Admin tier ClusterNetworkPolicies are evaluated before any other policies. Within the Admin tier, policies are processed in priority order (lowest priority number first). The action type determines what happens next:
    • Deny action (highest precedence): When an Admin policy with a Deny action matches traffic, that traffic is immediately blocked regardless of any other policies. No further ClusterNetworkPolicy or NetworkPolicy rules are processed. This ensures that organization-wide security controls cannot be overridden by namespace-level policies.
    • Allow action: After Deny rules are evaluated, Admin policies with Allow actions are processed in priority order (lowest priority number first). When an Allow action matches, the traffic is accepted and no further policy evaluation occurs. These policies can grant access across multiple namespaces based on label selectors, providing centralized control over which workloads can access specific resources.
    • Pass action: Pass actions in Admin tier policies delegate decision-making to lower tiers. When traffic matches a Pass rule, evaluation skips all remaining Admin tier rules for that traffic and proceeds directly to the NetworkPolicy tier. This allows administrators to explicitly delegate control for certain traffic patterns to application teams. For example, you might use Pass rules to delegate intra-namespace traffic management to namespace administrators while maintaining strict controls over external access.
  • Network policy tier: If no Admin tier policy matches with Deny or Allow, or if a Pass action was matched, namespace-scoped ApplicationNetworkPolicy and traditional NetworkPolicy resources are evaluated next. These policies provide fine-grained control within individual namespaces and are managed by application teams. Namespace-scoped policies can only be more restrictive than Admin policies. They cannot override an Admin policy’s Deny decision, but they can further restrict traffic that was allowed or passed by Admin policies.
  • Baseline tier Admin policies: If no Admin or namespace-scoped policies match the traffic, Baseline tier ClusterNetworkPolicies are evaluated. These provide default security postures that can be overridden by namespace-scoped policies, allowing administrators to set organization-wide defaults while giving teams flexibility to customize as needed. Baseline policies are evaluated in priority order (lowest priority number first).
  • Default deny (if no policies match): This deny-by-default behavior ensures that only explicitly permitted connections are allowed, maintaining a strong security posture.

 Applying the principle of least privilege

  • Start with restrictive policies and gradually add permissions as needed – Begin by implementing deny-by-default policies at the cluster level, then incrementally add allow rules as you validate legitimate connectivity requirements. This approach forces teams to explicitly justify each external connection, creating a more secure and auditable environment.
  • Regularly audit and remove unused policy rules – Network policies can accumulate over time as applications evolve, leaving behind obsolete rules that unnecessarily expand your attack surface. Implement a regular review process to identify and remove policy rules that are no longer needed, ensuring your security posture remains tight and maintainable.
  • Use specific domain names rather than broad patterns when possible – While wildcard patterns like *.amazonaws.com provide convenience, they also grant access to a wide range of services. Whenever feasible, specify exact domain names like s3.us-west-2.amazonaws.com to limit access to only the specific services your applications require, reducing the risk of lateral movement if a workload is compromised.

Validating your DNS policies

  • Use staging clusters that mirror production network topology for testing – Your staging environment should replicate the network architecture, external dependencies, and connectivity patterns of production to ensure accurate policy testing. This includes matching VPC configurations, DNS resolution behavior, and access to the same external services your production workloads require.
  • Implement automated testing for critical network paths – Build automated tests that validate connectivity to essential external services as part of your CI/CD pipeline. These tests should verify that legitimate traffic flows are permitted while unauthorized connections are blocked, providing continuous validation that your network policies maintain the correct security posture as your infrastructure evolves.
  • Monitor application behavior after policy changes – After deploying new or modified network policies to production, closely monitor application logs, error rates, and performance metrics to quickly identify any connectivity issues. Establish clear rollback procedures so you can rapidly revert policy changes if they cause unexpected application behavior or service disruptions.

Interaction with Amazon Route 53 DNS firewall

EKS Admin and Network policies are evaluated first at the pod level when traffic is initiated. If an EKS network policy allows egress to a specific domain, the pod then performs a DNS query that reaches the Route 53 Resolver. At this point, Route 53 DNS Firewall rules are evaluated. If DNS Firewall blocks the domain query, DNS resolution fails and the connection cannot be established, even though the EKS network policy allowed it. This creates complementary security layers: EKS DNS-based network policies provide pod-level egress control for application-specific access requirements and multi-tenant security boundaries, while DNS Firewall provides VPC-wide protection against known malicious domains and enforces organization-wide blocklists.

Conclusion

DNS and Admin network policies represent a significant advancement in Kubernetes network security, providing the granular control and operational simplicity that modern cloud-native applications require. As you continue to evolve your Kubernetes security strategy, Admin policies and DNS-based network policies provide the foundation for building robust, scalable, and maintainable network security controls that adapt to your infrastructure changes and support your organization’s growth.

About the authors

Alexandra Huides is a Principal Networking Specialist Solutions Architect in the AWS Networking Services product team at Amazon Web Services. She focuses on helping customers build and develop networking architectures for highly scalable and resilient AWS environments. Alex is also a public speaker for AWS, and is helping customers adopt IPv6. Outside work, she loves sailing, especially catamarans, traveling, discovering new cultures, running and reading.

Jeremy Cowan is a Specialist Solutions Architect for containers at AWS, although his family thinks he sells “cloud space”. Prior to joining AWS, Jeremy worked for several large software vendors, including VMware, Microsoft, and IBM. When he’s not working, you can usually find on a trail in the wilderness, far away from technology.

Vivek Bhadauria is a Software Development Engineer at Amazon Web Services, working on the EKS Networking team. He focuses on Kubernetes networking, DNS and building scalable, reliable cloud infrastructure. Vivek enjoys exploring distributed systems and sharing practical learnings through technical writing and open-source contributions.