# Minimize the admission of containers wishing to share the host network namespace

- Source: https://support.icompaas.com/support/solutions/articles/62000234629-minimize-the-admission-of-containers-wishing-to-share-the-host-network-namespace
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Azure Kubernetes Service (AKS) Benchmark v1.7.0](https://support.icompaas.com/support/solutions/62000112691) › [Azure Kubernetes Service (AKS) Benchmark](https://support.icompaas.com/support/solutions/folders/62000169257)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Profile Applicability:

-   Level 1
    

Description: Containers that share the host’s network namespace gain access to the host’s network interfaces and ports, which increases the risk of security vulnerabilities, especially if the container is compromised. This check ensures that containers are not allowed to share the host network namespace unless absolutely necessary.

Rationale: Allowing containers to share the host’s network namespace can expose the host to various network-related attacks, such as unauthorized access to ports and interfaces. Minimizing the use of the host network namespace ensures better isolation between containers and the host system, reducing the risk of privilege escalation or malicious behavior.

Impact:

-   Pros:
    
    -   Enhances the security of the host by ensuring containers do not have unnecessary access to the host's network.
        
    -   Reduces the attack surface for network-related exploits.
        
-   Cons:
    
    -   Some applications that require direct network access (e.g., monitoring or logging tools) may need to share the host network namespace.
        
    -   Restricting network namespace access may impact workloads that need specific network capabilities.
        

Default Value: By default, Kubernetes does not allow containers to share the host network namespace unless explicitly configured to do so.

Pre-requisites: Ensure that PodSecurityPolicies or other security configurations are in place to prevent containers from sharing the host network namespace unless necessary.

### **Remediation**

### **Test Plan:**

**Using Azure Console****:**

1.  Navigate to the Azure portal and review the configuration of the Kubernetes cluster.
    
2.  Check the pod specifications to see if hostNetwork is set to true.  
    
3.  Ensure that containers that do not require access to the host network do not have hostNetwork: true.  
    

Using Azure CLI:

1.  Use the following command to check if the hostNetwork flag is set for any containers:
    
     az aks show --resource-group <resource-group-name> --name <aks-cluster-name> --query "agentPoolProfiles\[\*\].vnetSubnetId"
    
      
    
2.  Ensure that the hostNetwork field is not set to true for containers unless absolutely required.
    

### **Implementation Plan:**

**Using Azure Console****:**

1.  Access the Azure portal to review the AKS cluster configuration.
    
2.  Modify the pod specifications to disable the hostNetwork setting for containers that do not require access to the host network.
    
3.  Set hostNetwork: false for the necessary pods.
    

Using Azure CLI:

1.  Update the pod configuration to prevent sharing the host network namespace by editing the pod spec:  
    
     kubectl edit deployment <deployment-name> --namespace=<namespace>
    
      
    
2.  Ensure the hostNetwork setting is explicitly set to false in the pod specification.
    

### **Backout Plan:**

**Using Azure Console****:**

1.  If restricting access to the host network namespace causes issues, revert the configuration in the Azure portal by enabling hostNetwork: true for the affected containers.
    

Using Azure CLI:

1.  Revert the hostNetwork setting by editing the pod or container spec to allow access to the host network namespace:
    
     kubectl edit deployment <deployment-name> --namespace=<namespace>
    
      
    
2.  Set hostNetwork: true for specific containers or pods where required.
    

### **References:**

1.  [Azure Kubernetes Service (AKS) Documentation](https://learn.microsoft.com/en-us/azure/aks/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.