What is the INGRESSCOOKIE cookie?
This cookie is used by the Kubernetes NGINX Ingress Controller to manage session affinity (sticky sessions) by routing requests from the same user to the same backend pod.
Table of Contents
About INGRESSCOOKIE
| Vendor | Kubernetes |
|---|---|
| Category Category The functional category of the technology, such as Web Analytics or Social Media. Learn more | Site Infrastructure & Security |
| Consent Category Consent Category The consent category this cookie most commonly falls under across sites we scan, normalized into four standard categories. Learn more | Strictly Necessary |
| Prevalence | Very Common |
| Popularity Popularity Popularity is calculated from our dataset of 4.5B+ cookies analyzed across hundreds of millions of web pages. Learn more | Found on 12.4% of scanned pages |
| Expiration Type | Session |
| Party Type Party Type Whether the cookie is first-party or third-party. Learn more | 3rd-Party |
| Risk Level Risk Level Rates how sensitive the data stored by this cookie is (High, Medium, or Low) based on data classification and distribution. Learn more | Low |
| Vendor Privacy Policy | https://kubernetes.io/docs/reference/policies/privacy/ |
| Vendor Website | https://kubernetes.io/ |
What is the purpose of INGRESSCOOKIE?
The INGRESSCOOKIE is the default session affinity (sticky session) cookie created by the Kubernetes community ingress-nginx (NGINX Ingress Controller) project. When a Kubernetes cluster uses NGINX to route incoming HTTP traffic, administrators can enable session affinity to ensure that subsequent requests from a specific user session are consistently routed to the same backend pod or server. This is critical for stateful applications or user sessions that require persistence.
When session stickiness is enabled and the nginx.ingress.kubernetes.io/affinity annotation is set to cookie, the controller injects this cookie into the client's browser with a value representing the specific backend pod. On subsequent requests, the browser sends the cookie back, and the NGINX Ingress Controller reads it to bypass the standard load-balancing algorithm and direct the traffic to the designated pod. While it does not contain personally identifiable information (PII) or user tracking data by default, it acts as a session identifier solely for load-balancing purposes. In ObservePoint scans, it is frequently observed as a 3rd-party cookie when a third-party vendor (e.g., an ad network) relies on a Kubernetes cluster that issues this cookie on its tag requests.
Note: the Kubernetes community ingress-nginx controller that sets this cookie by default reached end-of-life (retirement) in March 2026, so the project receives no further releases, bug fixes, or security updates. Existing deployments continue to function and may still emit this cookie. (This is distinct from the separate, still-supported F5/NGINX Inc. controller, nginxinc/kubernetes-ingress.)
What are the Privacy Risks of INGRESSCOOKIE?
Risk Level: Low
This cookie is strictly used for infrastructure load balancing and session stickiness. It does not capture cross-site behavioral tracking data, user profiles, or personally identifiable information (PII). Its value typically consists of an encrypted or hashed reference to the backend server pod, posing minimal privacy risk to the end user.
How to Remove INGRESSCOOKIE from a Website
Since this cookie is set by the Kubernetes NGINX Ingress Controller, website administrators can remove it by disabling session affinity in their cluster's Ingress resource configuration. Specifically, this is done by removing the nginx.ingress.kubernetes.io/affinity: "cookie" annotation from the corresponding Ingress YAML manifest and applying the changes. If session affinity is strictly required for the application to function properly, this cookie cannot be removed without breaking the application's statefulness. If the cookie is being set by a third-party vendor's infrastructure (such as an advertising or analytics endpoint, which is commonly observed for this cookie), it cannot be removed independently by the host website administrator; instead, the entire third-party tag must be removed to prevent the cookie from being set.