This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

There is no interest in the project to keep adding new annotations on-demand. The reason is that the volume of unique important use-cases is too large to cater to all expectations. Meaning if annotations are created for all requirements, then it becomes a combination of limited use of huge maintenance effort, of non-generic annotations or other features.

Secondly, the planning and execution of the Gateway API is already underway. The Gateway API will impact many expectations and alter designs. So adding annotations is not a improvement.

Thank you for your other contribution of gRPC_timeout annotation. That timeout annotation exists for HTTP but not for gRPC. So its a generic use-case for all gRPC deployments and hence its a improvement.

Wait for comments from others.

sure, i don't want to add annotations directly in this repo, that will bring chaos (like you said). 😄

i just want a mechanism that support custom annotations at runtime, like https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/custom-annotations/.

• the nginx.tmpl can be mounted to controller
• the annotations can be added to ingress, and only effect when it has been defined in nginx.tmpl

so, we don't need to create a full set of codes for annotation, just expose a map of variables for tmpl.

（let's see others 👍 ）

I don't think this project's controller has the design & architecture for supporting anything resembling dynamic runtime annotations.

Wait for other comments.

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

I have a similar use-case but for configuration-snippet. We have one ingress where we want to alter headers before the request is proxied to the backend. This requires us to enable allowSnippetAnnotations in our helm chart, but we are concerned about that because of the corresponding CVE.

I think having a feature such as this is a reasonable compromise. It would let you pre-define trusted custom snippets, and then opt-in usage of them where required. This contrasts how configuration-snippet and server-snippet work because they provide more surface area for arbitrary code to be set.

This could look like:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  allow-snippet-annotations: "false"
  enable-opentelemetry: "true"
  configuration-snippets: |
    - name: "add-foo-header"
      snippet: |
          add_header Foo "Bar";
    - name: "do-not-proxy-cookies"
      snippet: |
          proxy_set_header Cookie "";
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/enable-configuration-snippets: "add-foo-header,do-not-proxy-cookies"
  name: foo
  namespace: default
spec:
  ingressClassName: ingress-nginx
  rules:
  - host: foo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: backend
            port: 
              number: 80

I believe this is partially possible today, it requires you to mount a custom nginx template file, then you can add code like they have here in the NGINX ingress documentation.

Instead of doing {{if index $.Ingress.Annotations "custom.nginx.org/feature-a"}}, you would do something like (simplified) around here:

{{ $enabledConfigSnippets := index $ing.Annotations "nginx.ingress.kubernetes.io/enable-configuration-snippets" }}

{{ if not (empty $enabledConfigSnippets ) }}

 # use `split`[0], and look for exact values
{{ if contains $enabledConfigSnippets "do-not-proxy-cookies" }}
proxy_set_header Cookie "";
{{ end }}

{{ end }}

I think this could be simplified if it were a first class feature, plus you wouldn't need to maintain your own nginx template.

Links:

• 0:

  ingress-nginx/internal/ingress/controller/template/template.go

  Line 302 in 0edf16f

  "split": strings.Split,