<ahref="https://github.com/kubernetes/ingress-nginx/edit/master/docs/user-guide/nginx-configuration/annotations.md"title="Edit this page"class="md-icon md-content__icon"></a>
<p>You can add these Kubernetes annotations to specific Ingress objects to customize their behavior.</p>
<divclass="admonition tip">
<pclass="admonition-title">Tip</p>
<p>Annotation keys and values can only be strings.
Other types, such as boolean or numeric values must be quoted,
i.e. <codeclass="codehilite">"true"</code>, <codeclass="codehilite">"false"</code>, <codeclass="codehilite">"100"</code>.</p>
<p>In some scenarios the exposed URL in the backend service differs from the specified path in the Ingress rule. Without a rewrite any request will return 404.
Set the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/rewrite-target</code> to the path expected by the service.</p>
<p>If the application contains relative links it is possible to add an additional annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/add-base-url</code> that will prepend a <ahref="https://developer.mozilla.org/en/docs/Web/HTML/Element/base"><codeclass="codehilite">base</code> tag</a> in the header of the returned HTML from the backend.</p>
<p>If the scheme of <ahref="https://developer.mozilla.org/en/docs/Web/HTML/Element/base"><codeclass="codehilite">base</code> tag</a> need to be specific, set the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/base-url-scheme</code> to the scheme such as <codeclass="codehilite">http</code> and <codeclass="codehilite">https</code>.</p>
<p>If the Application Root is exposed in a different path and needs to be redirected, set the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/app-root</code> to redirect requests for <codeclass="codehilite">/</code>.</p>
<p>The annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/affinity</code> enables and sets the affinity type in all Upstreams of an Ingress. This way, a request will always be directed to the same upstream server.
The only affinity type available for NGINX is <codeclass="codehilite">cookie</code>.</p>
<p>If you use the <codeclass="codehilite">cookie</code> affinity type you can also specify the name of the cookie that will be used to route the requests with the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/session-cookie-name</code>. The default is to create a cookie named 'INGRESSCOOKIE'.</p>
<p>In case of NGINX the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/session-cookie-hash</code> defines which algorithm will be used to hash the used upstream. Default value is <codeclass="codehilite">md5</code> and possible values are <codeclass="codehilite">md5</code>, <codeclass="codehilite">sha1</code> and <codeclass="codehilite">index</code>.</p>
<divclass="admonition attention">
<pclass="admonition-title">Attention</p>
<p>The <codeclass="codehilite">index</code> option is not an actual hash; an in-memory index is used instead, which has less overhead.
However, with <codeclass="codehilite">index</code>, matching against a changing upstream server list is inconsistent.
So, at reload, if upstream servers have changed, index values are not guaranteed to correspond to the same server as before!
<strong>Use <codeclass="codehilite">index</code> with caution</strong> and only if you need to!</p>
</div>
<p>In NGINX this feature is implemented by the third party module <ahref="https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng">nginx-sticky-module-ng</a>. The workflow used to define which upstream server will be used is explained <ahref="https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/raw/08a395c66e425540982c00482f55034e1fee67b6/docs/sticky.pdf">here</a></p>
<p>Is possible to add authentication adding additional annotations in the Ingress rule. The source of the authentication is a secret that contains usernames and passwords inside the key <codeclass="codehilite">auth</code>.</p>
<p>The name of the Secret that contains the usernames and passwords which are granted access to the <codeclass="codehilite">path</code>s defined in the Ingress rules.
This annotation also accepts the alternative form "namespace/secretName", in which case the Secret lookup is performed in the referenced namespace instead of the Ingress namespace.</p>
<p>NGINX exposes some flags in the <ahref="http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream">upstream configuration</a> that enable the configuration of each server in the upstream. The Ingress controller allows custom <codeclass="codehilite">max_fails</code> and <codeclass="codehilite">fail_timeout</code> parameters in a global context using <codeclass="codehilite">upstream-max-fails</code> and <codeclass="codehilite">upstream-fail-timeout</code> in the NGINX ConfigMap or in a particular Ingress rule. <codeclass="codehilite">upstream-max-fails</code> defaults to 0. This means NGINX will respect the container's <codeclass="codehilite">readinessProbe</code> if it is defined. If there is no probe and no values for <codeclass="codehilite">upstream-max-fails</code> NGINX will continue to send traffic to the container.</p>
<p>With the default configuration NGINX will not health check your backends. Whenever the endpoints controller notices a readiness probe failure, that pod's IP will be removed from the list of endpoints. This will trigger the NGINX controller to also remove it from the upstreams.**</p>
<p>To use custom values in an Ingress rule define these annotations:</p>
<p><codeclass="codehilite">nginx.ingress.kubernetes.io/upstream-max-fails</code>: number of unsuccessful attempts to communicate with the server that should occur in the duration set by the <codeclass="codehilite">upstream-fail-timeout</code> parameter to consider the server unavailable.</p>
<p><codeclass="codehilite">nginx.ingress.kubernetes.io/upstream-fail-timeout</code>: time in seconds during which the specified number of unsuccessful attempts to communicate with the server should occur to consider the server unavailable. This is also the period of time the server will be considered unavailable.</p>
<p>In NGINX, backend server pools are called "<ahref="http://nginx.org/en/docs/http/ngx_http_upstream_module.html">upstreams</a>". Each upstream contains the endpoints for a service. An upstream is created for each service that has Ingress rules defined.</p>
<p>NGINX supports load balancing by client-server mapping based on <ahref="http://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash">consistent hashing</a> for a given key. The key can contain text, variables or any combination thereof. This feature allows for request stickiness other than client IP or cookies. The <ahref="http://www.last.fm/user/RJ/journal/2007/04/10/392555/">ketama</a> consistent hashing method will be used which ensures only a few keys would be remapped to different servers on upstream group changes.</p>
<p>To enable consistent hashing for a backend:</p>
<p><codeclass="codehilite">nginx.ingress.kubernetes.io/upstream-hash-by</code>: the nginx variable, text value or any combination thereof to use for consistent hashing. For example <codeclass="codehilite">nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri"</code> to consistently hash upstream requests by the current request URI.</p>
<p>This is similar to (https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/configmap.md#load-balance) but configures load balancing algorithm per ingress.</p>
<blockquote>
<p>Note that <codeclass="codehilite">nginx.ingress.kubernetes.io/upstream-hash-by</code> takes preference over this. If this and <codeclass="codehilite">nginx.ingress.kubernetes.io/upstream-hash-by</code> are not set then we fallback to using globally configured load balancing algorithm.</p>
<p>This configuration setting allows you to control the value for host in the following statement: <codeclass="codehilite">proxy_set_header Host $host</code>, which forms part of the location block. This is useful if you need to call the upstream server by something other than <codeclass="codehilite">$host</code>.</p>
The name of the Secret that contains the full Certificate Authority chain <codeclass="codehilite">ca.crt</code> that is enabled to authenticate against this Ingress.
This annotation also accepts the alternative form "namespace/secretName", in which case the Secret lookup is performed in the referenced namespace instead of the Ingress namespace.</li>
<p>Cloudflare only allows Authenticated Origin Pulls and is required to use their own certificate: <ahref="https://blog.cloudflare.com/protecting-the-origin-with-tls-authenticated-origin-pulls/">https://blog.cloudflare.com/protecting-the-origin-with-tls-authenticated-origin-pulls/</a></p>
<p>Only Authenticated Origin Pulls are allowed and can be configured by following their tutorial: <ahref="https://support.cloudflare.com/hc/en-us/articles/204494148-Setting-up-NGINX-to-use-TLS-Authenticated-Origin-Pulls">https://support.cloudflare.com/hc/en-us/articles/204494148-Setting-up-NGINX-to-use-TLS-Authenticated-Origin-Pulls</a></p>
This is a global configuration for the ingress controller. In some cases could be required to return a custom content or format. In this scenario we can use the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/default-backend: <svc name></code> to specify a custom default backend.</p>
controls what's the accepted Origin for CORS and defaults to '*'.
This is a single field value, with the following format: <codeclass="codehilite">http(s)://origin-site.com</code> or <codeclass="codehilite">http(s)://origin-site.com:port</code>
<p>To add Server Aliases to an Ingress rule add the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/server-alias: "<alias>"</code>.
<p>For more information please see <ahref="http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name">the <codeclass="codehilite">server_name</code> documentation</a>.</p>
<p>Using the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/server-snippet</code> it is possible to add custom configuration in the server configuration block.</p>
<p>To use an existing service that provides authentication the Ingress rule can be annotated with <codeclass="codehilite">nginx.ingress.kubernetes.io/auth-url</code> to indicate the URL where the HTTP request should be sent.</p>
<codeclass="codehilite"><Response_Header_1, ..., Response_Header_n></code> to specify headers to pass to backend once authentication request completes.</li>
<p>These annotations define a limit on the connections that can be opened by a single client IP address.
This can be used to mitigate <ahref="https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus">DDoS Attacks</a>.</p>
<ul>
<li><codeclass="codehilite">nginx.ingress.kubernetes.io/limit-connections</code>: number of concurrent connections allowed from a single IP address.</li>
<li><codeclass="codehilite">nginx.ingress.kubernetes.io/limit-rps</code>: number of connections that may be accepted from a given IP each second.</li>
<li><codeclass="codehilite">nginx.ingress.kubernetes.io/limit-rpm</code>: number of connections that may be accepted from a given IP each minute.</li>
<li><codeclass="codehilite">nginx.ingress.kubernetes.io/limit-rate-after</code>: sets the initial amount after which the further transmission of a response to a client will be rate limited.</li>
<li><codeclass="codehilite">nginx.ingress.kubernetes.io/limit-rate</code>: rate of request that accepted from a client each second.</li>
<p>You can specify the client IP source ranges to be excluded from rate-limiting through the <codeclass="codehilite">nginx.ingress.kubernetes.io/limit-whitelist</code> annotation. The value is a comma separated list of CIDRs.</p>
<p>If you specify multiple annotations in a single Ingress rule, <codeclass="codehilite">limit-rpm</code>, and then <codeclass="codehilite">limit-rps</code> takes precedence.</p>
<p>The annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/limit-rate</code>, <codeclass="codehilite">nginx.ingress.kubernetes.io/limit-rate-after</code> define a limit the rate of response transmission to a client. The rate is specified in bytes per second. The zero value disables rate limiting. The limit is set per a request, and so if a client simultaneously opens two connections, the overall rate will be twice as much as the specified limit.</p>
<p>To configure this setting globally for all Ingress rules, the <codeclass="codehilite">limit-rate-after</code> and <codeclass="codehilite">limit-rate</code> value may be set in the <ahref="../configmap/">NGINX ConfigMap</a>. if you set the value in ingress annotation will cover global setting.</p>
<p>This annotation allows to return a permanent redirect instead of sending data to the upstream. For example <codeclass="codehilite">nginx.ingress.kubernetes.io/permanent-redirect: https://www.google.com</code> would redirect everything to Google.</p>
<p>The annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/ssl-passthrough</code> allows to configure TLS termination in the pod and not in NGINX.</p>
<p>By default NGINX uses plain HTTP to reach the services.
Adding the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/secure-backends: "true"</code> in the Ingress rule changes the protocol to HTTPS.
If you want to validate the upstream against a specific certificate, you can create a secret with it and reference the secret with the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/secure-verify-ca-secret</code>.</p>
<p>By default the NGINX ingress controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration.</p>
<p>The <codeclass="codehilite">nginx.ingress.kubernetes.io/service-upstream</code> annotation disables that behavior and instead uses a single upstream in NGINX, the service's Cluster IP and port.</p>
<p>This can be desirable for things like zero-downtime deployments as it reduces the need to reload NGINX configuration when Pods come up and down. See issue <ahref="https://github.com/kubernetes/ingress-nginx/issues/257">#257</a>.</p>
<p>If the <codeclass="codehilite">service-upstream</code> annotation is specified the following things should be taken into consideration:</p>
<ul>
<li>Sticky Sessions will not work as only round-robin load balancing is supported.</li>
<li>The <codeclass="codehilite">proxy_next_upstream</code> directive will not have any effect meaning on error the request will not be dispatched to another upstream.</li>
</ul>
<h3id="server-side-https-enforcement-through-redirect">Server-side HTTPS enforcement through redirect<aclass="headerlink"href="#server-side-https-enforcement-through-redirect"title="Permanent link">¶</a></h3>
<p>By default the controller redirects (308) to HTTPS if TLS is enabled for that ingress.
If you want to disable this behavior globally, you can use <codeclass="codehilite">ssl-redirect: "false"</code> in the NGINX <ahref="../configmap/">config map</a>.</p>
<p>To configure this feature for specific ingress resources, you can use the <codeclass="codehilite">nginx.ingress.kubernetes.io/ssl-redirect: "false"</code>
annotation in the particular resource.</p>
<p>When using SSL offloading outside of cluster (e.g. AWS ELB) it may be useful to enforce a redirect to HTTPS
even when there is no TLS certificate available.
This can be achieved by using the <codeclass="codehilite">nginx.ingress.kubernetes.io/force-ssl-redirect: "true"</code> annotation in the particular resource.</p>
<p>In some scenarios is required to redirect from <codeclass="codehilite">www.domain.com</code> to <codeclass="codehilite">domain.com</code> or vice versa.
<p>If at some point a new Ingress is created with a host equal to one of the options (like <codeclass="codehilite">domain.com</code>) the annotation will be omitted.</p>
<p>You can specify allowed client IP source ranges through the <codeclass="codehilite">nginx.ingress.kubernetes.io/whitelist-source-range</code> annotation.
The value is a comma separated list of <ahref="https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing">CIDRs</a>, e.g. <codeclass="codehilite">10.0.0.0/24,172.10.0.1</code>.</p>
<p>To configure this setting globally for all Ingress rules, the <codeclass="codehilite">whitelist-source-range</code> value may be set in the <ahref="../configmap/">NGINX ConfigMap</a>.</p>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>Adding an annotation to an Ingress rule overrides any global restriction.</p>
<p>With the annotations <codeclass="codehilite">nginx.ingress.kubernetes.io/proxy-redirect-from</code> and <codeclass="codehilite">nginx.ingress.kubernetes.io/proxy-redirect-to</code> it is possible to
set the text that should be changed in the <codeclass="codehilite">Location</code> and <codeclass="codehilite">Refresh</code> header fields of a proxied server response (http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect)</p>
<p>Setting "off" or "default" in the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/proxy-redirect-from</code> disables <codeclass="codehilite">nginx.ingress.kubernetes.io/proxy-redirect-to</code>,
otherwise, both annotations must be used in unison. Note that each annotation must be a string without spaces.</p>
<p>By default the value of each annotation is "off".</p>
<p>For NGINX, an 413 error will be returned to the client when the size in a request exceeds the maximum allowed size of the client request body. This size can be configured by the parameter <ahref="http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size"><codeclass="codehilite">client_max_body_size</code></a>.</p>
<p>To configure this setting globally for all Ingress rules, the <codeclass="codehilite">proxy-body-size</code> value may be set in the <ahref="../configmap/">NGINX ConfigMap</a>.
<p>Sets a text that <ahref="http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cookie_domain">should be changed in the domain attribute</a> of the "Set-Cookie" header fields of a proxied server response.</p>
<p>To configure this setting globally for all Ingress rules, the <codeclass="codehilite">proxy-cookie-domain</code> value may be set in the <ahref="../configmap/">NGINX ConfigMap</a>.</p>
By default proxy buffering is disabled in the NGINX config.</p>
<p>To configure this setting globally for all Ingress rules, the <codeclass="codehilite">proxy-buffering</code> value may be set in the <ahref="../configmap/">NGINX ConfigMap</a>.
<p>Sets the size of the buffer <ahref="http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size"><codeclass="codehilite">proxy_buffer_size</code></a> used for reading the first part of the response received from the proxied server.
By default proxy buffer size is set as "4k"</p>
<p>To configure this setting globally, set <codeclass="codehilite">proxy-buffer-size</code> in <ahref="../configmap/">NGINX ConfigMap</a>. To use custom values in an Ingress rule, define this annotation:</p>
<p>Specifies the <ahref="http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers">enabled ciphers</a>.</p>
<p>Using this annotation will set the <codeclass="codehilite">ssl_ciphers</code> directive at the server level. This configuration is active for all the paths in the host.</p>
<p>Using <codeclass="codehilite">lua-resty-waf-*</code> annotations we can enable and control the <ahref="https://github.com/p0pr0ck5/lua-resty-waf">lua-resty-waf</a>
Web Application Firewall per location.</p>
<p>Following configuration will enable the WAF for the paths defined in the corresponding ingress:</p>
<p>In order to run it in debugging mode you can set <codeclass="codehilite">nginx.ingress.kubernetes.io/lua-resty-waf-debug</code> to <codeclass="codehilite">"true"</code> in addition to the above configuration.
The other possible values for <codeclass="codehilite">nginx.ingress.kubernetes.io/lua-resty-waf</code> are <codeclass="codehilite">inactive</code> and <codeclass="codehilite">simulate</code>.
In <codeclass="codehilite">inactive</code> mode WAF won't do anything, whereas in <codeclass="codehilite">simulate</code> mode it will log a warning message if there's a matching WAF rule for given request. This is useful to debug a rule and eliminate possible false positives before fully deploying it.</p>
<p><codeclass="codehilite">lua-resty-waf</code> comes with predefined set of rules <ahref="https://github.com/p0pr0ck5/lua-resty-waf/tree/84b4f40362500dd0cb98b9e71b5875cb1a40f1ad/rules">https://github.com/p0pr0ck5/lua-resty-waf/tree/84b4f40362500dd0cb98b9e71b5875cb1a40f1ad/rules</a> that covers ModSecurity CRS.
You can use <codeclass="codehilite">nginx.ingress.kubernetes.io/lua-resty-waf-ignore-rulesets</code> to ignore a subset of those rulesets. For an example:</p>
<p>It is also possible to configure custom WAF rules per ingress using the <codeclass="codehilite">nginx.ingress.kubernetes.io/lua-resty-waf-extra-rules</code> annotation. For an example the following snippet will configure a WAF rule to deny requests with query string value that contains word <codeclass="codehilite">foo</code>:</p>
<p>For details on how to write WAF rules, please refer to <ahref="https://github.com/p0pr0ck5/lua-resty-waf">https://github.com/p0pr0ck5/lua-resty-waf</a>.</p>
<p>You only need to add the annotation <codeclass="codehilite">nginx.ingress.kubernetes.io/grpc-backend: "true"</code> to enable this feature.
Additionally, if the gRPC service requires TLS, add <codeclass="codehilite">nginx.ingress.kubernetes.io/secure-backends: "true"</code>.</p>
<divclass="admonition attention">
<pclass="admonition-title">Attention</p>
<p>This feature requires HTTP2 to work which means we need to expose this service using HTTPS.
Exposing a gRPC service using HTTP is not supported.</p>
<p>Using <codeclass="codehilite">influxdb-*</code> annotations we can monitor requests passing through a Location by sending them to an InfluxDB backend exposing the UDP socket
using the <ahref="https://github.com/influxdata/nginx-influxdb-module/">nginx-influxdb-module</a>.</p>
<p>For the <codeclass="codehilite">influxdb-host</code> parameter you have two options:</p>
<p>To use the module in the Kubernetes Nginx ingress controller, you have two options:</p>
<ul>
<li>Use an InfluxDB server configured to enable the <ahref="https://docs.influxdata.com/influxdb/v1.5/supported_protocols/udp/">UDP protocol</a>.</li>
<li>Deploy Telegraf as a sidecar proxy to the Ingress controller configured to listen UDP with the <ahref="https://github.com/influxdata/telegraf/tree/release-1.6/plugins/inputs/socket_listener">socket listener input</a> and to write using
anyone of the <ahref="https://github.com/influxdata/telegraf/tree/release-1.6/plugins/outputs">outputs plugins</a></li>
