Istio is one of the most popular open-source service meshes used to connect, manage, and secure microservices in modern environments. However, in versions 1.12. and 1.12.1, a security vulnerability (CVE-2022-21701) was discovered that could let some users escalate their privileges. In this post, we’ll break down the vulnerability, what caused it, how it can be exploited, and most importantly, what you should do about it.

What is CVE-2022-21701?

This vulnerability affects Istio’s support for the Kubernetes Gateway API—a relatively new feature at the time and still in Alpha. Here’s the core issue:

Who is vulnerable? Anyone running Istio 1.12. or 1.12.1 with the Kubernetes Gateway API enabled.

- Who can exploit it? Any user with CREATE permission for the gateways.gateway.networking.k8s.io Kubernetes object (a kind of CustomResourceDefinition or CRD).
- What can an attacker do? Abuse that privilege to create other resources (like Pods) they shouldn’t be able to create.

> Note: This does not affect Istio Gateways managed by the older resource gateways.networking.istio.io.

Why Does This Happen?

The problem comes from the way Istio managed certain permissions around new Gateway API resources. If someone has permission to create Gateway CRDs, they could craft a special object that triggers Istio’s control plane to create additional Kubernetes objects with more permissions than the user actually had. This amounts to a privilege escalation.

Demonstrating the Exploit

Let’s see a simplified version of how this could be abused.

All an attacker needs is CREATE access to gateways.gateway.networking.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: vulnerable-namespace
  name: gateway-creator
rules:
- apiGroups: ["gateway.networking.k8s.io"]
  resources: ["gateways"]
  verbs: ["create"]

2. Abusive Gateway Resource

The attacker creates a malicious Gateway object. Through improper reconciliation, Istio may then create a Pod or other privileged resource on their behalf.

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: evil-gateway
spec:
  gatewayClassName: istio
  listeners:
  - protocol: HTTP
    port: 80
  # Additional configuration here can trick Istio into deploying resources

> The specific technique relies on alpha-stage implementation bugs that let the Gateway’s configuration propagate in unintended ways, allowing unauthorized resource creation.

3. Gaining Pod or Other Access

By manipulating the Gateway configuration, this could, under the vulnerability, indirectly cause Istio to apply a resource such as a Pod that the user shouldn’t have been able to create due to their original RBAC permissions.

Official References

- CVE Entry on NVD
- Istio Security Bulletin (January 2022)
- GitHub Issue

How to Fix or Mitigate

If you can upgrade:  
The issue was fixed in Istio 1.12.2. Upgrading Istio will close the security hole.

Change Istiod Configuration

Set the environment variable PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER=true on every Istiod pod to enable the fixed controller:

Conclusion

If you use Istio’s Alpha Gateway API or are not sure, you should check your Istio version and whoever on your team or external teams have permissions over Gateway CRDs. Even if only internal teams have this access, you should upgrade or tightly lock down your RBAC to prevent accidental exploitation.

Remember:  
This does not affect the regular Istio Gateway kind or the older gateway configuration, only the *new Kubernetes Gateway API*.

Stay secure: Upgrade, restrict, or disable what you don’t need.

Further Reading:  
- Kubernetes Gateway API documentation
- Istio Security Best Practices

Timeline

Published on: 01/19/2022 22:15:00 UTC
Last modified on: 01/27/2022 14:03:00 UTC