Skip to content
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

Adds support for root context redirection #427

Merged
merged 5 commits into from
Mar 16, 2017

Conversation

rikatz
Copy link
Contributor

@rikatz rikatz commented Mar 12, 2017

This PR adds support for Root Context Redirection.

This is necessary for some Apps (as Java Apps) that aren't created containing a root context, but instead answers only its context.

An example, a Java App that exposes itself as '/app1'. When you create an Ingress, you need to redirect the call to 'app1.ingress.com/' to 'app1.ingress.com/app1'.

TODO:

  • Make some real test in my production environment to check the behaviour
  • Improve the rewrite module documentation.

After I finish documentating this, the PR is ready.

@jcmoraisjr Please take a look to see if this is applicable to our case.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Mar 12, 2017
@k8s-reviewable
Copy link

This change is Reviewable

@rikatz rikatz changed the title WIP: Adds support for root context redirection Adds support for root context redirection Mar 13, 2017
@rikatz
Copy link
Contributor Author

rikatz commented Mar 13, 2017

@aledbf Don't know why CI failed, as those were simple changes.

Can you help me in this to check if this is a real failure?

Thanks!

@aledbf aledbf closed this Mar 13, 2017
@aledbf aledbf reopened this Mar 13, 2017
@coveralls
Copy link

Coverage Status

Coverage increased (+0.04%) to 43.277% when pulling 0e5d3ca on rikatz:app-root-redirect into 0cb8f59 on kubernetes:master.

@rikatz
Copy link
Contributor Author

rikatz commented Mar 13, 2017

Tks :D

@@ -1,3 +1,28 @@
# Sticky Session

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be Rewrite ?

@jcmoraisjr
Copy link
Contributor

@jcmoraisjr Please take a look to see if this is applicable to our case.

@rikatz Sound good. Btw the 302 redirect is indeed a nice choice.

Awaiting this PR merged to add this feature to HAProxy Ingress as well =) Thanks!

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.08%) to 43.165% when pulling 98abd6d on rikatz:app-root-redirect into 0cb8f59 on kubernetes:master.

@aledbf aledbf self-assigned this Mar 15, 2017
@aledbf
Copy link
Member

aledbf commented Mar 15, 2017

@rikatz just one change, plese move examples/rewrite/* to examples/rewrite/nginx/

@rikatz
Copy link
Contributor Author

rikatz commented Mar 16, 2017

OK, made it as asked.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.02%) to 43.266% when pulling 6f25329 on rikatz:app-root-redirect into 0cb8f59 on kubernetes:master.

@rikatz
Copy link
Contributor Author

rikatz commented Mar 16, 2017

@aledbf Travis / Coveralls seems to be broken :( My last commit only moved the Example as you requested, but the CI broke :(

@aledbf aledbf closed this Mar 16, 2017
@aledbf aledbf reopened this Mar 16, 2017
@coveralls
Copy link

Coverage Status

Coverage increased (+0.02%) to 43.266% when pulling 6f25329 on rikatz:app-root-redirect into 0cb8f59 on kubernetes:master.

@aledbf
Copy link
Member

aledbf commented Mar 16, 2017

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 16, 2017
@aledbf aledbf merged commit c25936d into kubernetes:master Mar 16, 2017
@aledbf
Copy link
Member

aledbf commented Mar 16, 2017

@rikatz thanks!

@@ -236,7 +236,19 @@ http {
ssl_verify_client on;
ssl_verify_depth {{ $location.CertificateAuth.ValidationDepth }};
{{ end }}

{{ if (or $location.Redirect.ForceSSLRedirect (and (not (empty $server.SSLCertificate)) $location.Redirect.SSLRedirect)) }}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aledbf this seems broken. I think it should be moved back into the location {{path}} block.

What happens if we have one location with ssl-redirect: "false" and one with ssl-redirect: "true" - won't they now both be redirected?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rikatz please check ^^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aledbf I've only changed the piece of code from it's location. The idea is first make it's HTTPs redirection based on the configs (as defined previous in lines 282:287 and then moved to this new location) and then redirect (if it exists) to the root context.

One doesn't exclude other, this code existed previously. It only orders which rules will be followed first :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, acording to NGINX docs, the IF and redirects can happen inside a location, a if and a server directive. The usage of this directive inside the 'location' limits the redirection only for the current location (maybe only the '/' path), not containing the other paths that might exist.

I'm on vacation (and traveling) right now, but will take a look again in this behaviour ASAP.

@jasonbrownbridge How have you detected this? Can you please reproduce the taken steps, so I can try here and take a look.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rikatz I was thinking something like this (substituting in appropriate ssl-wildcard secret):

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default-route
  annotations:
    kubernetes.io/ingress.class: "nginx"
    kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts:
      - "*.example.com"
      secretName: "ssl-wildcard"
  rules:
  - host: "www.example.com"
    http:
      paths:
      - path: /
        backend:
          serviceName: route-default
          servicePort: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: check-route
  annotations:
    kubernetes.io/ingress.class: "nginx"
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: "www.example.com"
    http:
      paths:
      - path: /check
        backend:
          serviceName: route-check
          servicePort: 80

My thought is this should create something like:

 server {
    server_name www.example.com;
    ...
    location / {
        if ($pass_access_scheme = http) {
            return 301 https://$host$request_uri;
        }
        ...
    }
    location /check {
        ...
    }

Instead this code would generate (which always does ssl redirect):

 server {
    server_name www.example.com;
    ...
    if ($pass_access_scheme = http) {
        return 301 https://$host$request_uri;
    }
    location / {
        ...
    }
    location /check {
        ...
    }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rikatz will try do a more concrete test case tomorrow (UTC+2 here)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also @rikatz I'm not blocked here (I use a custom template anyway) - so enjoy your vacation :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasonbrownbridge We all do :P I've removed all the passthrough stuff, as I use only HTTP/s traffic.

Anyway, I think the idea is to always redirect the SSL, as this is a global annotation, isn't it?

This '/check', by the otherside could be inside the same Ingress Object (of the vhost that contains the TLS config). I suppose that Ingress Controller assumes the first created ingress and discards the conflicting one. (you have two ingress objects pointing to the same host, in this case www.example.com)

Also, by the previous template (before this commit), the HTTPs redirection would be inserted anyway in all existing 'path' rules :)

But let me know about your tests!

@aledbf Am I right with this conclusion?

@rikatz rikatz deleted the app-root-redirect branch March 27, 2017 23:50
@piclemx
Copy link

piclemx commented Apr 4, 2017

Do you know when this will be in a beta?

@rikatz rikatz mentioned this pull request Jun 12, 2017
ankon added a commit to Collaborne/ingress that referenced this pull request Jun 28, 2017
This is needed to avoid ingress definitions with different settings for SSL
redirection conflicting with each other.

NB: This was discussed in the review of kubernetes#427, but ultimately not addressed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants