CVE-2022-3162: Kubernetes Auth Bypass Vulnerability

CVE-2022-3162 Overview

CVE-2022-3162 is an authorization bypass vulnerability in Kubernetes that allows users with cluster-wide list or watch authorization on one type of namespaced custom resource to read custom resources of a different type within the same API group without proper authorization. This vulnerability affects Kubernetes clusters where multiple CustomResourceDefinitions (CRDs) share the same API group and users have partial access permissions.

Critical Impact

Unauthorized users can gain read access to sensitive custom resources they should not have permission to view, potentially exposing confidential configuration data, secrets, or operational information stored in custom resources across the cluster.

Affected Products

• Kubernetes (multiple versions affected)
• Kubernetes clusters with 2+ CustomResourceDefinitions sharing the same API group
• Environments where users have partial cluster-wide list/watch permissions on custom resources

Discovery Timeline

• 2023-03-01 - CVE-2022-3162 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-3162

Vulnerability Analysis

This authorization bypass vulnerability stems from improper access control enforcement in Kubernetes' handling of custom resources within shared API groups. When a user has been granted cluster-wide list or watch permissions on one custom resource type, the authorization system fails to properly isolate access to other custom resource types within the same API group.

For a cluster to be vulnerable, three conditions must be met simultaneously: there must be two or more CustomResourceDefinitions sharing the same API group, users must have cluster-wide list or watch authorization on at least one of those custom resources, and those same users must lack authorization to read another custom resource in the same API group. When all conditions are present, the authorization boundary between custom resource types breaks down.

Root Cause

The root cause is a path traversal weakness (CWE-22, CWE-23) in how Kubernetes validates and enforces authorization boundaries between custom resources sharing an API group. The API server does not adequately verify that list or watch requests are scoped only to the specific custom resource type the user is authorized to access, allowing requests to traverse into unauthorized resource types within the same API group context.

Attack Vector

An attacker with legitimate but limited access to a Kubernetes cluster can exploit this vulnerability through the network. The attack requires low-privilege credentials that have cluster-wide list or watch permissions on at least one custom resource. Using these permissions, the attacker can craft API requests to enumerate and read custom resources of different types within the same API group, bypassing the intended authorization controls.

The exploitation does not require user interaction and can be performed remotely through standard Kubernetes API calls. The attacker gains unauthorized read access to potentially sensitive custom resource data, though no integrity or availability impact has been identified.

Detection Methods for CVE-2022-3162

Indicators of Compromise

• Unusual API requests for custom resources from users who should not have access to specific resource types
• Audit log entries showing list or watch operations across multiple custom resource types from the same user account
• Access patterns indicating enumeration of custom resources across an API group
• Unexpected data access by service accounts with limited intended permissions

Detection Strategies

• Enable and monitor Kubernetes audit logs for anomalous custom resource access patterns
• Implement RBAC policy analysis to identify overly permissive cluster-wide list/watch permissions
• Deploy runtime security monitoring to detect unauthorized resource enumeration
• Configure alerts for users accessing custom resources outside their normal operational scope

Monitoring Recommendations

• Regularly audit CustomResourceDefinitions to identify API groups with multiple CRD types
• Review user and service account permissions for unnecessary cluster-wide list/watch grants
• Monitor API server logs for cross-resource type access within shared API groups
• Implement behavioral baselines for custom resource access patterns per user/service account

How to Mitigate CVE-2022-3162

Immediate Actions Required

• Audit all RBAC policies to identify users with cluster-wide list or watch permissions on custom resources
• Review CustomResourceDefinitions to understand which resources share API groups
• Apply the principle of least privilege by restricting cluster-wide permissions to namespace-scoped where possible
• Update Kubernetes to a patched version as documented in the security advisory

Patch Information

Kubernetes has released patches addressing this vulnerability. Administrators should consult the Kubernetes Security Announcement and the GitHub Issue Discussion for detailed patch information and affected version ranges. Organizations using Kubernetes in NetApp environments should also review the NetApp Security Advisory for additional guidance.

Workarounds

• Segregate CustomResourceDefinitions into separate API groups where feasible to prevent cross-resource access
• Restrict cluster-wide list and watch permissions to namespace-scoped permissions where operationally possible
• Implement network policies to limit which users and service accounts can interact with the API server
• Deploy admission controllers to enforce stricter RBAC policies on custom resource access

# Review RBAC permissions for cluster-wide custom resource access
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.kind=="ClusterRole") | {name: .metadata.name, subjects: .subjects}'

# List all CustomResourceDefinitions and their API groups
kubectl get crd -o custom-columns=NAME:.metadata.name,GROUP:.spec.group

# Audit cluster roles with list/watch permissions on custom resources
kubectl get clusterroles -o json | jq '.items[] | select(.rules[].resources | contains(["*"]) or any(. | test("customresourcedefinitions|crd"))) | .metadata.name'