Ingress Nginx Controller to Nginx Ingress Controller translation help

Projects NGINX Ingress Controller
, , ,
1

Please use this template for troubleshooting questions.

My issue: I am trying to use ingress Kind to replace the annotations that I have used in ingress nginx controller and now to Nginx ingress controller. However, I am unable to solve this.

**How I encountered the problem: We are migrating from ingress nginx controller to nginx ingress controller and stuck at converting the following annotations,
**
kubernetes.io/ingress.class: nginx-device (We started using ingressClassName for this)

**nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream**: "true"

**nginx.ingress.kubernetes.io/auth-tls-secret**: ingress-nginx/ca-cert

**nginx.ingress.kubernetes.io/auth-tls-verify-client**: optional

**nginx.ingress.kubernetes.io/auth-tls-verify-depth**: "4"

nginx.ingress.kubernetes.io/configuration-snippet: |. *(We found out we can use location-snippet for this)*

  rewrite /ws/(.\*) /ws/$1 break;

  rewrite /ws.\* /ws break;

  proxy_set_header ssl-client-serial $ssl_client_serial;

  proxy_set_header ssl-client-s-dn $ssl_client_s_dn_legacy;

**nginx.ingress.kubernetes.io/proxy-read-timeout**: "300"

Solutions I’ve tried: We have tried nginx.org replacement of following annotations but didn’t work. We have also tried moving in most of them as some alternative into location-snippet instead of configuration-snippet. Still enforced client authentication is not happening. We are trying to find a solution avoiding virtualServer and ceritificatePolicy CRDs. Kindy let us know if we can achieve this translation.

Version of NIC and/or NGINX: image: Quay

Deployment environment: Kubernetes cluster

1 Like
2

Hi @parallel_stories thank you for contacting us about this query. Can you confirm the upstream is performing TLS validation?

1 Like
3

Hi @Paul_Abel Thanks for reaching out.
The downstream is already passing the identity via proxy_set_header for the upstream backend app. So, yes, we are not performing TLS validation at upstream

2 Likes
4

Hi @parallel_stories,

Sorry to sideline :slight_smile:, but as @Paul_Abel is reviewing this I wanted to check with you.. As you mentioned, mTLS is possible with our VirtualServer CRDs by attaching a Policy to them. We have many types of policies, including one specifically for mTLS, and this use case can be achieved with our CRDs, which are generally more stable and native than annotations (we invested in CRD’s to avoid annotation sprawl). Snippets are an option, but they are not always ideal (e.g. the snippet would need to reference the k8s secret for the CA for mTLS)..

We do receive requests like this to support more annotations (we are working through a list right now), even though most of the use cases can already be addressed with our CRDs. Many users prefer to use Ingress as their primary resource. In response, we are exploring the possibility of allowing certain Policy CRDs to be “attached” directly to an Ingress, without requiring a VirtualServer.

For example, this would let users create a Policy CRD and reference it with an Ingress instead of a VirtualServer, so they can keep using Ingress while still benefiting from the better policy model. This approach would allow us to support more of the use cases we already fulfil today with Policy CRDs, without having to introduce and maintain a large set of new annotations.
​
General question: would you consider something like this acceptable in your environment (attaching a CRD Policy to an Ingress)? Or are CRDs a complete no‑go for you in general?

1 Like
5

Hi @Micheal_Kingston

Thanks for your detailed explanation about VirtualServer option and Policy CRDs.
However, at our scale, we are avoiding new CRDs. We want to move from ingress nginx controller to nginx ingress controller mainly because of its sole and unique advantage in supporting ingresses.

We would appreciate if we can let us a way that would support mTLS through the ingress only.

Thanks again

1 Like
6

I believe I have come up with a solution for you to allow mTLS on an Ingress by making use of volumeMounts and annotation snippets.

You would need to mount the CA secret into the NGINX Ingress Controller deployment. I have provided our helm values but a similar approach would work for manifests.

controller:
  volumes:
    - name: ingress-secret
      secret:
        secretName: ca-cert
  volumeMounts:
    - name: ingress-secret
      mountPath: /etc/nginx/ssl/ingress-ca.crt
      subPath: ca.crt

Annotations on Ingress resource

    nginx.org/proxy-read-timeout: "300s"
    nginx.org/server-snippets: |
      ssl_verify_client optional;
      ssl_verify_depth 4;
      ssl_client_certificate /etc/nginx/ssl/ingress-ca.crt;
    nginx.org/location-snippets: |
      proxy_set_header ssl-client-cert $ssl_client_escaped_cert;
      proxy_set_header ssl-client-verify $ssl_client_verify;
      proxy_set_header ssl-client-subject-dn $ssl_client_s_dn;
      proxy_set_header ssl-client-issuer-dn $ssl_client_i_dn;
      proxy_set_header ssl-client-serial $ssl_client_serial;
      proxy_set_header ssl-client-s-dn $ssl_client_s_dn_legacy;

Hopefully this will let you progress with your migration. Please let us know if this helped.

2 Likes
7

Thank you for a prompt solution on this. I will be trying this and will be getting back to you.

2 Likes
8

Hi @Paul_Abel Thank you very much for the solution.
It did made the ws handshake successful. :smiley:
However, we are seeing few errors. I want to confirm either its from client or BE app side further. Kindly give us couple of days to get back. Till then requesting to keep this discussion open.

1 Like
9

No problem @parallel_stories
Let us know if we can assist further.