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.

I have been able to achieve my objective by doing the following:

• Add the following configuration to the ingress-nginx controller confg map:

  http-snippet: |
    proxy_ssl_verify       on;
    proxy_ssl_verify_depth 5;
    proxy_ssl_protocols    TLSv1.2 TLSv1.3;
    proxy_ssl_trusted_certificate /etc/nginx/ca-root-bundle.pem;
    proxy_ssl_ciphers      HIGH:!aNULL:!MD5;

• Add the following annotations to my ingress:

    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/server-snippet: |
      proxy_ssl_name          <<cluster-service-fqdn>>;
      proxy_ssl_session_reuse on;

• Inject a volume into the controller to present my trusted CA certificate bundle at /etc/nginx/ca-root-bundle.pem

/assign @rikatz

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 the same issue and I plan to provide a PR to quickly address the issue

I commented that you may not want to use client cert auth, but you need to tell the controller about the CA that signed the certificate that is being presented by the HTTPS server at the backend, over on the other side of the "backend-protocol: HTTP" annotation. See below

There has been no user updates since a year so there is no action item on the project here.

The fundamental issue is an expectation to use SSL/TLS and yet not require the CA and other details. That is just not feasible as that approach increases risk of unauthorized connection.

This can be discussed in the community meetings if the user joins or in slack. But there is no action item here on the project so closing this issue. The tally of open issues without action items is in hundreds so closing this issue until a action item emerges from this issue.

/close

@longwuyuan: Closing this issue.

There are multiple issues and PRs that are all linked to the same underlying issue. We can keep this closed and refer to #10557 for example.

The current implementation is clearly favouring the mTLS use case at the expense of absolutely standard server authentication modes (as used by almost every public website and many other systems). The other PRs can be used and there's no further update from me because I am using the configuration snippet approach to work around this limitation.

To be clear, mTLS adds overhead and in many cases it isn't necessary or worthwhile. Without the base server authentication, the client cannot trust that the hop is safely encrypted. But client authentication (i.e. adding mTLS) only proves the identity of the sending server to the receiving server, but often this is accomplished with other data in the transmission, so it is a completely separate design choice. Not least because it is only proving the sender is the ingress reverse proxy, not even the originating client here. That can equally be accomplished by network security policies, for example.

@staizen-stephen grateful for your comments.

There are more updates that may help move this discussion forward.

• There is no contention that some users would benefit from the implementation that is being expressed/proposed here. I agree 100% on that.

• But there is no data that ALL users would prefer default as that backend-protocol: HTTPS not verifying CA/Other etc. To the best of our knowledge, its only some users. Hence the decision to implement what you expect could "potentially" be done. But it will require to be optional (with a configMap/annotaion/flag etc) and default behavior.

• Now this update comes in the backlight that the project has deprecated many useful and popular features (like TCP/UDP forwarding for example) due to shortage of resources to maintain/support them. So there is not much chance that the project can allocate resources on this.

• And then finally comes the update that there have been CVEs that got highlighted big time. And then there are CVEs (for which we are constantly patching when possible) that are re-occurring all the time so-to-speak related to the SSL libs. So there was a lot of resources required and resulted in a change of direction, like giving priority to decure-by-default shipping of the controller. Hence there is very little chance that the collective decision will come down to allocating resources, to implement a new capability of the controller, that allows TLS without CA (even between internal hops). Even K8S internal hops don't do TLS without CA.

The creator of the issue can very well re-open the issue and that would be welcome. But the hope is that re-opening the issue starts tracking a action item on someone. The project is unfortunately in no position to allocate resources.

Absolutely fine. And fully understand the resource pressures.

I would add that I'm not trying to remove verification, actually my entire goal was to ensure that verification was taking place against a certificate authority that was configured to be trusted by the host and injected into the container as well. In my case I simply did not have a client certificate and secret available to supply.

Again, no issues closing this. Thanks for your fast response.