HSTS not supported with VS

[ElvenSpellmaker]

Describe the bug Using Nginx Ingress when I try to apply ssl-redirect and hsts they don't seem to be working.

Going to foo.foo.com gives me http with no redirect.

To Reproduce As per: https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/

Note it says that ssl-redirect is on by default but it doesn't appear to be. 🤔

A ConfigMap like the following: https://user-images.githubusercontent.com/2286713/132874484-d5d30bee-437c-42f2-be2b-03d55f569e11.png

Nginx configuration like so: yml - name: nginx-ingress image: 'nginx/nginx-ingress:1.8.1' args: - '-nginx-configmaps=$(POD_NAMESPACE)/nginx-config' - '-default-server-tls-secret=$(POD_NAMESPACE)/default-server-secret' - '-global-configuration=$(POD_NAMESPACE)/nginx-configuration'

(Note if the ConfigMap doesn't exist it will fail to start so it's clearly reading it but not doing anything with the values.)

VirtualServers like the following: yml apiVersion: k8s.nginx.org/v1 metadata: name: foo namespace: foo kind: VirtualServer spec: host: foo.foo.com routes: - action: pass: foo path: / tls: secret: wildcard-tls upstreams: - name: foo port: 80 service: foo tls: enable: false

Expected behavior When going to foo.foo.com a SSL 301 redirect should be present and an HSTS header on the redirected content.

additional

trying to set up HSTS on their Ingress Controller, but the configmap keys don't seem to want to add the nginx directives to their VS/VSR resources.> I'm also trying to set this up in my lab and having no luck with getting any hsts directives put in the nginx.conf files.> Do we have any examples for adding hsts to VS/VSR, either through the configmap or any other method?

Aha! Link: https://nginx.aha.io/features/IC-303

[github-actions[bot]]

Hi @ElvenSpellmaker thanks for reporting!

Be sure to check out the docs while you wait for a human to take a look at this 🙂

Cheers!

[ElvenSpellmaker]

Hi @ElvenSpellmaker thanks for reporting!

Be sure to check out the docs while you wait for a human to take a look at this 🙂

Cheers!

I did 🙂

[ElvenSpellmaker]

I think I've found this:

I assume this is why, so is it no longer possibly to apply a blanket SSL redirect on a global level? What about HSTS?

[ElvenSpellmaker]

I also see this:

But I can't see a way to set HSTS on a VirtualServer level...

[ElvenSpellmaker]

So it looks like there's no way to enforce HSTS at all (without enabling snippets perhaps) and no way to globally redirect to HTTPS.

[brianehlert]

Two ways to handle redirecting to HTTPS

• setting the value specifically for each VS
• defining a VS that listens for all incoming http and forwards to https

Doing it at the VS level gives the granular control, in case there is a path that is not wanted to be redirected.
There should be a way to define one VS that results in the same behavior. let me check.

[pleshakov]

@ElvenSpellmaker @brianehlert
Yep, the ConfigMap ssl-redirect and hsts are not supported by VirtualServer

I can suggest a workaround - you can put the following into the ConfigMap which will enable both TLS redirects and HSTS for VirtualServers:

data:
  server-snippets: |
    proxy_hide_header Strict-Transport-Security;
    set $hsts_header_val "";
    if ($scheme = 'https') {
      set $hsts_header_val "max-age=31536000";
    }
    add_header Strict-Transport-Security "$hsts_header_val" always;
    if ($scheme  = 'http') {
      return 302 https://$host$request_uri;
    }

Now if we deploy this example -- https://github.com/nginxinc/kubernetes-ingress/tree/master/examples-of-custom-resources/basic-configuration -- and apply that ConfigMap, we will get:

curl -I http://cafe.example.com/coffee
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.21.3
Date: Fri, 17 Sep 2021 17:14:07 GMT
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://cafe.example.com/coffee

curl -I https://cafe.example.com/coffee -sk
HTTP/1.1 200 OK
Server: nginx/1.21.3
Date: Fri, 17 Sep 2021 17:14:33 GMT
Content-Type: text/plain
Content-Length: 160
Connection: keep-alive
Expires: Fri, 17 Sep 2021 17:14:32 GMT
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000

[nmagesh84]

For me too, config map ssl-protocols setting TLSV1.2 is not working.

I am connecting .NET C# application hosted in Azure to Azure File Share.

Azure File Share requires TLS 1.2 version and I have configured the same in nginx configmap using ssl-protocol argument.

I still get SSL handshake error.

[ElvenSpellmaker]

@ElvenSpellmaker @brianehlert Yep, the ConfigMap ssl-redirect and hsts are not supported by VirtualServer

I can suggest a workaround - you can put the following into the ConfigMap which will enable both TLS redirects and HSTS for VirtualServers:

data:
  server-snippets: |
    proxy_hide_header Strict-Transport-Security;
    set $hsts_header_val "";
    if ($scheme = 'https') {
      set $hsts_header_val "max-age=31536000";
    }
    add_header Strict-Transport-Security "$hsts_header_val" always;
    if ($scheme  = 'http') {
      return 302 https://$host$request_uri;
    }

Now if we deploy this example -- master/examples-of-custom-resources/basic-configuration -- and apply that ConfigMap, we will get:

curl -I http://cafe.example.com/coffee
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.21.3
Date: Fri, 17 Sep 2021 17:14:07 GMT
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://cafe.example.com/coffee

curl -I https://cafe.example.com/coffee -sk
HTTP/1.1 200 OK
Server: nginx/1.21.3
Date: Fri, 17 Sep 2021 17:14:33 GMT
Content-Type: text/plain
Content-Length: 160
Connection: keep-alive
Expires: Fri, 17 Sep 2021 17:14:32 GMT
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000

But this has to be applied per VirtualServer which is really clunky and won't fly with any compliance team.

Are VirtualServers considered deprecated for native Ingress objects which do support these options?

[brianehlert]

NGINX Ingress Controller is moving forward with the CRDs. VirtualServer, VirtualServerRoute, TransportServer, Policy.
This is where new capabilities are being added and existing capabilities expanded.

[jjngx]

Answered 3 years ago. Closing.

[ElvenSpellmaker]

I suppose the question I asked last is still unanswered, would it want a new ticket? Having to apply this to each resource is really clunky and prone to being missed out.

Unless there's now a way to force this on a higher level in the 3 years this has been open?

It doesn't seem great that the accepted way of doing this is per-resource when the Ingress resource is supported on the Config level instead...

[jjngx]

Please open a new discussion that reflect current version of NIC.