-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS to backends - server-only authentication and per-location SSL config #4688
Comments
I have a similar issue to this in that I need TLS client authentication on specific paths within a host. However, it appears that can can only be configured at the host level. |
@tonyplovich I would like to ask for some details with regard to your case: do you want to have TLS for some specific paths while for other paths there should be no TLS within a host? |
TLS should always be active on the host, but certain paths should require a
valid client cert. For example:
/someApp/x509 <-- request client TLS cert
/someApp/thing1 <-- no auth
/someApp/thing2 <-- no auth
Admittedly, I'm not too familiar with Nginx, and assumed it would be
possible to set something like ssl_verify_client per location/path since
I've done this before in Apache. Looking at the docs it doesn't look like
it can be set within a location context
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client.
…On Tue, Nov 12, 2019 at 3:13 AM Laszlo Janosi ***@***.***> wrote:
@tonyplovich <https://github.com/tonyplovich> I would like to ask for
some details with regard to your case: do you want to have TLS for some
specific paths while for other paths there should be no TLS within a host?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4688?email_source=notifications&email_token=AFYTJNSBIPIHRBTCNUVCGTLQTJXSZA5CNFSM4JBYUELKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZRXAA#issuecomment-552803200>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFYTJNSK6RPP332VNWZ2OLLQTJXSZANCNFSM4JBYUELA>
.
|
Hi @janosi |
Hello @afsilvasantos, Yes, there is a solution for this: the ingress-nginx ConfigMap parameter |
Hi @janosi |
@afsilvasantos You can use any name you like. Then you have to pass the name of the ConfigMap to the ingress controller with the The "ingress-controller-leader-nginx" CM is used by the ingress controller for leader election, so please use another one. |
Oh ok, thanks a lot @janosi |
It did not seem to work, or maybe i have some different requirements that will not work with my use case. I am trying to verify the client with "auth-tls-verify-client" annotation, and not using the "proxy-ssl-*" annotations. Because i want to authenticate the client connecting to the Nginx, and not the proxied service to nginx, don't know if i am being clear about it |
@afsilvasantos Yes, indeed, that is a different use case. Please see the example here how to set up cert based client authentication. https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/ |
Exactly @janosi |
@afsilvasantos Yep, the TLS config for the host in the Ingress is server level config in nginx, so once set in an Ingress resource that setting is applied on all Ingress resources with the same host. Even if the other Ingresses do not have this configured. It is not ingress-nginx specific, but client authentication related directives are server level in nginx, i.e. those cannot be defined for the locations individually http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client |
Thanks a lot for your time. Now at least i know that it does not work as i intended to and don't have to waste any more time |
No problem. Excuse me that I misunderstood your real problem. |
Is this a request for help? No
What keywords did you search in NGINX Ingress controller issues before filing this one? I tested the ingress controller
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT
NGINX Ingress controller version: 0.26.1
Kubernetes version (use
kubectl version
): 1.15Environment:
uname -a
):What happened:
The secret referred in the annotation
nginx.ingress.kubernetes.io/proxy-ssl-secret
contained only a ca.crt. I.e. no tls.crt, nor tls.key. It was to test the one-way authentication of the backend. The outcome: The parameters proxy_ssl_certificate and proxy_ssl_certificate_key in nginx.conf pointed to the file that contained only the ca.crt. I was not able to access the backend service because nginx could not read the tls.key and the tls.crt from the rerefenced file.I defined multiple Ingresses. Those had the same host but different paths and different proxy-ssl-secrets. That is, I wanted to create a setup in which the different locations (backend services) of the same server (host) can use different SSL configs. The outcome: the controller logic merges those Ingresses as they refer to the same host (it is OK), but the controller created the proxy_ssl_* configuration on server level, and
it selected the first (alphabetically) proxy-ssl-secret from all the Ingresses. I.e. it forced the same proxy_ssl_* config for all locations under the server.
What you expected to happen:
I expected to have a successful outcome with oneway auth executed. The nginx.config should have only proxy_ssl_trusted_certificate pointing to the file that contains the ca.crt, and it should not have proxy_ssl_certificate and proxy_ssl_certificate_key parameters for this case.
When the controller merges the locations under the same server in the nginx.conf file, it should not try to force a single proxy_ssl_* config on all locations. Instead, the controller shall create the proxy_ssl_* config on location level.
How to reproduce it (as minimally and precisely as possible):
Refer to such a secret in the annotation
nginx.ingress.kubernetes.io/proxy-ssl-secret
that contains only a ca.crt.Create multiple Ingresses that point to the same host in the rules, but defines different locations, and use different proxy-ssl-secret values in those Ingresses.
Anything else we need to know:
The text was updated successfully, but these errors were encountered: