# Ensure that the authorization mode Argument is Not Set to AlwaysAllow

- Source: https://support.icompaas.com/support/solutions/articles/62000234176-ensure-that-the-authorization-mode-argument-is-not-set-to-alwaysallow
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Amazon EKS](https://support.icompaas.com/support/solutions/62000112685) › [CIS Amazon Elastic Kubernetes Service (EKS) Benchmark](https://support.icompaas.com/support/solutions/folders/62000169234)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:** • **Level 1**

**Description:** Do not allow all requests. Ensure that explicit authorization is enforced by setting the authorization-mode to Webhook instead of AlwaysAllow.

**Rationale:** Kubelets configured with authorization-mode=AlwaysAllow permit all authenticated (and sometimes even anonymous) requests without any additional authorization checks. This creates a significant security gap. Setting the mode to Webhook ensures requests are subject to authorization decisions based on RBAC or external webhook services.

**Impact:  
 Pros:**

-   Enforces strict access control for kubelet operations.
    
-   Prevents privilege escalation and unauthorized node access.
    
-   Ensures kubelet only serves requests from authorized users/services.
    

**Cons:**

-   May deny requests that previously worked under AlwaysAllow.
    
-   Requires a properly configured authorization system (Webhook or RBAC).  
    

**Default Value:** May vary depending on the Kubernetes version and base AMI. Check AWS EKS-specific documentation.

**Pre-requisites:**

-   SSH or Session Manager access to the worker nodes.
    
-   Permissions to view and edit Kubelet config or service definition files.
    
-   Ability to restart systemd services (for systemd-based environments).
    
-   Kubernetes access to test via configz or deploy a privileged pod.
    

### **Remediation**

**Test Plan:**

**Using AWS Console:**

1.  Go to Amazon EC2 > Instances, connect to a worker node using Session Manager or EC2 Instance Connect.
    
2.  Run the following command to check the kubelet process and find config file path:
    
    -   ps -ef | grep kubelet
        
3.  Open the config file using:
    
    -   sudo less /path/to/kubelet-config.json
        
4.  Check the following entry exists:  
     "authorization": { "mode": "Webhook" }
    
5.  Also verify that the --authorization-mode flag is not set to AlwaysAllow.
    

**Using AWS CLI:**

1.  Get the list of nodes:  
    
    kubectl get nodes
    

2.  Start a proxy to use /configz:  
    
    kubectl proxy --port=8080
    

3.  In a new terminal:  
    
    export NODE\_NAME=my-node-name
    curl http://localhost:8080/api/v1/nodes/${NODE\_NAME}/proxy/configz
    

4.  Check the returned JSON contains:  
    
    "authorization": { "mode": "Webhook" }
    

5.  Confirm it's not set to AlwaysAllow.  
    

### **Implementation Plan**

**Using AWS Console:**

1.  Connect to the worker node using EC2 or Session Manager.
    
2.  Run ps -ef | grep kubelet and locate the --config argument if present.
    
3.  Open the config file and ensure the following entry is set:  
    "authorization": { "mode": "Webhook" }
    

4.  If using systemd (EKS Optimized AMIs), navigate to:  
    /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
    

5.  Ensure the following line is added or modified:  
    \--authorization-mode=Webhook
    

6.  Save the changes and restart the kubelet service.
    

**Using AWS CLI:**

1.  Edit the kubelet config file on the node and ensure the following is present:  
    
    "authorization": { "mode": "Webhook" }
    

2.  Or modify the systemd unit file and add:  
    
    \--authorization-mode=Webhook
    

3.  Restart services:  
    
    systemctl daemon-reload
     systemctl restart kubelet.service
    systemctl status kubelet -l
    

### **Backout Plan**

**Using AWS Console:**

1.  Reconnect to the node.
    
2.  Revert any changes made to the kubelet config file or service files.
    
3.  Restart kubelet after rollback.
    

**Using AWS CLI:**

1.  Remove or reset the --authorization-mode flag if needed.
    
2.  Reapply the previous config file version if backed up.
    
3.  Restart kubelet:  
    
    systemctl daemon-reload
    systemctl restart kubelet.service
    

### **References:**

1.  [Kubelet CLI Reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)
    
2.  Kubelet Authentication and Authorization
    
3.  [Kubelet Config API](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/)

## 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.