Closed PeterAndreus closed 6 months ago
@PeterAndreus: This issue is currently awaiting triage.
If a SIG or subproject 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.
/sig network
/transfer ingress-nginx
Can you try pathType value as Exact and update.
Thanks, ; Long
On Mon, 4 Apr, 2022, 9:00 AM Peter Andreus, @.***> wrote:
What happened?
In my project i need rewrite one path in ingress, so i looked at documentation: https://kubernetes.github.io/ingress-nginx/examples/rewrite/
My ingress:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: is meta.helm.sh/release-namespace: is-dev nginx.ingress.kubernetes.io/rewrite-target: /$2 creationTimestamp: "2022-04-01T05:35:01Z" generation: 1 labels: app.kubernetes.io/instance: is app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: backend-rest helm.sh/chart: backend-0.1.0 name: is-backend-rest namespace: is-dev resourceVersion: "352279575" uid: a1dc501e-3c12-46c7-a543-3db921433c81 spec: rules:
- host: foo.bar.sk http: paths:
- backend: service: name: is-backend port: name: http path: /rest(/|$)(.*) pathType: Prefix tls:
- hosts:
- foo.bar.sk
another Ingress specification:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: meta.helm.sh/release-name: is meta.helm.sh/release-namespace: is-dev creationTimestamp: "2022-04-01T05:35:02Z" generation: 1 labels: app.kubernetes.io/instance: is app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: reg helm.sh/chart: reg-0.1.0 name: is-reg namespace: is-dev resourceVersion: "352259630" uid: 68708a7d-3169-4e5a-a9f2-ca7db507fcb8 spec: rules:
- host: foo.bar.sk http: paths:
- backend: service: name: is-reg port: name: http path: /reg pathType: Prefix tls:
- hosts:
- foo.bar.sk
Rewrite works fine, access to reg services too. HOWEVER When there is rewrite target annotation i can access even foo.bar.sk/regSomething/url. If i disable rewrite target annotation, foo.bar.sk/regSomething/url is not accesible, like it should not be, because its not specified in Ingress.
Made some digging and found out that when rewrite annotation is applied, generated nginx configuration file looks like this:
location ~ "^/rest(/|$)(.)" {
....
location ~* "^/reg" {
And when no rewrite annotation is applied generated config looks like:
location = /rest(/|$)(.*) {
...
location = /reg {
What did you expect to happen?
After rewrite-target annotation in one ingress rule other ingress rules in namespace should stay unchanged. How can we reproduce it (as minimally and precisely as possible)?
kind: Pod apiVersion: v1 metadata: name: apple-app labels: app: apple spec: containers:
- name: apple-app image: hashicorp/http-echo args:
- "-text=apple"
kind: Service apiVersion: v1 metadata: name: apple-service spec: selector: app: apple ports:
- port: 5678 name: http
kind: Pod apiVersion: v1 metadata: name: banana-app labels: app: banana spec: containers:
- name: banana-app image: hashicorp/http-echo args:
- "-text=banana"
kind: Service apiVersion: v1 metadata: name: banana-service spec: selector: app: banana ports:
- port: 5678 name: http
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: rules:
- host: foo.bar.sk http: paths:
- path: /apple(/|$)(.*) pathType: Prefix backend: service: name: apple-service port: name: http
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress2 spec: rules:
- host: foo.bar.sk http: paths:
- path: /ba pathType: Prefix backend: service: name: banana-service port: name: http
https://foo.bar.sk/apple => returns "apple" https://foo.bar.sk/ba => returns "banana" https://foo.bar.sk/banana => returns "banana" since it should not Anything else we need to know?
No response Kubernetes version
$ kubectl version Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:30:33Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.7", GitCommit:"1f86634ff08f37e54e8bfcd86bc90b61c98f84d4", GitTreeState:"clean", BuildDate:"2021-11-17T14:35:38Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}
Cloud provider OS version
On Linux:
$ cat /etc/os-release NAME="Ubuntu"VERSION="20.04.3 LTS (Focal Fossa)"ID=ubuntuID_LIKE=debianPRETTY_NAME="Ubuntu 20.04.3 LTS"VERSION_ID="20.04"HOME_URL="https://www.ubuntu.com/"SUPPORT_URL="https://help.ubuntu.com/"BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"VERSION_CODENAME=focalUBUNTU_CODENAME=focal
Install tools Container runtime (CRI) and version (if applicable) Related plugins (CNI, CSI, ...) and versions (if applicable)
— Reply to this email directly, view it on GitHub https://github.com/kubernetes/ingress-nginx/issues/8425, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGZVWXANS3USUNDS2YY6CTVDJO5BANCNFSM5SOF3BRQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Exact should not be considered as solution because different logic in working with url, but even with "Exact" pathType this bug occurs and i can acces urls i should not.
I tried:
and with rewrite-target rule in different ingress i can access http://foo.bar.sk/banana/test
(1) Please provide the information that is requested in the issue template
(2) Please post the output of kubectl describe ing -A -o wide
(3) Please post the exact curl command and its output
(4) Please post the logs of the controller pod that are related to your curl command(s)
(5) You are not discussing the fact that you are using regexp group $2 and not $1 but the requested url you posted does not even have a second regexp group. Explain why
You can actually make faster progress if you discuss this in Kubernetes.slack.com in the ingress-nginx-users channel. There is less resources here and much much resources on slack.
/remove-kind bug /kind support
(1) I provided all necessary, mandatory informations. Edited first post to delete parts that are not related to this issue (2) working with Example setup i posted in first comment: Example-ingress
Example-ingress2
(3):
The only correct response that should occur based on example-ingress2
$ curl http://foo.bar.sk/ba
banana
Response that should NOT occur based on example-ingress2
$ curl http://foo.bar.sk/banana/app/test/whatever
banana
(4) Logs of banana pod
$ k logs -n isis-dev banana-app
2022/04/04 06:21:36 Server is listening on :5678
2022/04/04 06:21:43 foo.bar.sk 10.42.2.233:51264 "GET /ba HTTP/1.1" 200 7 "curl/7.58.0" 100.412µs
2022/04/04 06:21:46 foo.bar.sk 10.42.2.233:51290 "GET /banana/app/test/whatever HTTP/1.1" 200 7 "curl/7.58.0" 62.908µs
(5) Im trying to post in most simplicity i can, problem is not about rewriting path, problem is that annotation in FIRST ingress affects rules in SECOND ingress According to examples at documentation https://kubernetes.io/docs/concepts/services-networking/ingress/ second curl should NOT respond
Curl commands of SECOND ingress after removing rewrite-target annotation in FIRST ingress (correct behaviour):
$ curl http://foo.bar.sk/ba
banana
$ curl http://foo.bar.sk/banana
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
$ curl http://foo.bar.sk/banana/app/test/whatever
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
Banana pod logs without rewrite-target annotation in different ingress:
$ k logs -n isis-dev banana-app
2022/04/04 06:34:25 Server is listening on :5678
2022/04/04 06:34:29 foo.bar.sk 10.42.2.233:46658 "GET /ba HTTP/1.1" 200 7 "curl/7.58.0" 18.944µs
I also joined channel on slack but it seems there are just questions, not answers
Are you expecting a request for this url http://foo.bar.sk/banana/app/test/whatever
, to match the rules configured in the ingress object called example-ingress2
?
Thats the point that url should not match rules in example-ingress2
However when there is rewrite-target annotation in example-ingress
(different ingress in same namespace) that url is accessible via match in example-ingress2
do you see both rules configured for the same server block in nginx.conf ?
When the see the kubectl describe
output of example-ingress2 and the requested URL as http://foo.bar.sk/banana/app/test/whatever
, I suspect the existence of string "ba" in the path, right after /
, is a match. If yo can show kubectl get ing example-ingress2 -o yaml
maybe we can know more as to why you think there should not be a match.
also, did you even try a curl exactly as described in the documentation you have referenced. Maybe you should configure your ingress for the exact same path as shown in the example, and with exact same pathType and then send a request for the exact same URL as described in example.
Its not a apples to apples comparison, if you compare path "/aaa/bb" with the path you have configured. Also its not a apples to apples comparison, when you compare the URL in the example with the URL you have requested in your curl command.
Generated nginx.conf with rewrite-target annotation (templating is messed up with this, so i upload at pastebin): https://pastebin.com/raw/vxLxjDz3
Generated nginx.conf without rewrite-target annotation: https://pastebin.com/raw/ARPg2bpr
So yes, both rules are in same server block. Notice differences in location rules as i mentioned in first post
kubectl get ing example-ingress2 -o yaml
I configured example-ingress2
same as in example:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress2
spec:
rules:
- host: foo.bar.sk
http:
paths:
- path: /aaa/bb
pathType: Prefix
backend:
service:
name: banana-service
port:
name: http
This ingress should match only /aaa/bb according to example in documentation, however:
$ curl foo.bar.sk/aaa/bbb
banana
And as im writing since beggining, when i remove rewrite-target annotation in example-ingress
, matching in example-ingress2
is as in example and /aaa/bbb is not match
This update has information but like I have been hinting, can you show the log for this curl command request.
My request is that in one single post here, please show the entire information related to one http request. That means ;
date
prefixIn your last curl command, you did not show logs because ingress controller can never ever give you a response if there was no matching rule. So some rule matched to give you the response as "banana"
$ kubectl get ing -A -o wide
$ kubectl describe ing -A
$ kubectl get sec -A -o wide | grep -I ingress
error: the server doesn't have a resource type "sec"
CURL:
$ curl foo.bar.sk/aaa/bbb -v
* Trying 192.168.190.182...
* TCP_NODELAY set
* Connected to foo.bar.sk (192.168.190.182) port 80 (#0)
> GET /aaa/bbb HTTP/1.1
> Host: foo.bar.sk
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 04 Apr 2022 09:09:41 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 7
< Connection: keep-alive
< X-App-Name: http-echo
< X-App-Version: 0.2.3
<
banana
* Connection #0 to host foo.bar.sk left intact
LOGS of bannana pod
$ k logs -n isis-dev banana-app
2022/04/04 07:24:28 Server is listening on :5678
2022/04/04 07:25:33 foo.bar.sk 10.42.2.233:45936 "GET /bbb HTTP/1.1" 200 7 "curl/7.58.0" 14.289µs
2022/04/04 07:25:35 foo.bar.sk 10.42.2.233:45962 "GET /bb HTTP/1.1" 200 7 "curl/7.58.0" 40.86µs
2022/04/04 07:35:09 foo.bar.sk 10.42.2.233:49906 "GET /aaa/bbb HTTP/1.1" 200 7 "curl/7.58.0" 14.462µs
2022/04/04 07:35:11 foo.bar.sk 10.42.2.233:49918 "GET /aaa/bb HTTP/1.1" 200 7 "curl/7.58.0" 9.402µs
2022/04/04 07:46:55 foo.bar.sk 10.42.2.233:54726 "GET /aaa/bb HTTP/1.1" 200 7 "curl/7.58.0" 11.963µs
2022/04/04 09:04:37 foo.bar.sk 10.42.2.233:58132 "GET /aaa/bbb HTTP/1.1" 200 7 "curl/7.58.0" 28.553µs
2022/04/04 09:08:06 foo.bar.sk 10.42.2.233:59552 "GET /aaa/bbb HTTP/1.1" 200 7 "curl/7.58.0" 26.033µs
2022/04/04 09:09:41 foo.bar.sk 10.42.2.233:60202 "GET /aaa/bbb HTTP/1.1" 200 7 "curl/7.58.0" 10.168µs
As i said problem is in generated nginx.conf that i pasted in previous comment not in ingress configuration: nginx.conf when no rewrite-target is applied has this location rules:
location = /ba {
location /ba/ {
so only foo.bar.sk/ba or foo.bar.sk/ba/ is match
However nginx.conf when rewrite-target is applied in any ingress has this location rules:
location ~* "^/ba" {
location ~* "^/ba/" {
so anything that starts with foo.bar.sk/ba mathces If i read correctly, ~ means that nginx matches case insensitive regex, and ^ in regex means starts with so `location ~ "^/ba" ` matches url which starts with /ba, so /banana for example
I would assume that when i add rewrite-target annotation to ingress with match - path: /apple(/|$)(.*)
generated nginx.conf should have rewrite only location location ~* "^/apple(/|$)(.*)"
not some /ba location defined in another ingress
of-course the first matching rule will get processed. I responded to you on slack https://kubernetes.slack.com/archives/CANQGM8BA/p1649052053515279
how did you install ingress-nginx controller ? On which environment are you running the cluster ? Please post the information requested in the issue template. The screenshot below does not show how you installed ingress-nginx controller
on a zoom session, it was determined that the problem to be solved is whitelisting based on path.
Hence use of whitelisting annotation on a ingress object that shared host with other ingress objects but the path is unique.
Hi,
Has any progress been made on this?
I think I am hitting a related same issue on v1.0.4
I have a development environment with a hostname such as foo.bar.sk, the ingress would be
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress-root
spec:
rules:
- host: foo.bar.sk
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: banana-service
port:
name: http
Then I am creating release branches that have a path prefix /apple, using ingresses configured exactly as example-ingress
in the minimum reproducible example, with the same hostname foo.bar.sk
If both ingresses with the same hostname are present I start getting randomly get 404 from queries to foo.bar.sk/apple
Can this be linked to the bad interaction described in this ticket?
For fqdn foo.bar.com if you have Prefix / and Prefix /apple, then Prefix / will match anything and everything sent to foo.bar.com (unless you have rules blocking that). Hence it will help if someone provides the required details because I still don't understand what is the problem to be solved.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
@PeterAndreus the issue-description revolves around the location block created when the rewrite annotation is in use.
But since beginning till the end, the authenticity of the reports is missing the critical info like ;
And this issue has been without traction for 2 years.
I think it will take the info that I listed here above and more to establish what problem needs to be solved in the controller. Currently this issue contains a expectation on what the server blocks should contain as location blocks.
Add to that, there is some validations in paths that is new to this issue.
There are too many issues that are inactive with non-conclusive data so no action-item is clear from the data in the issue. This being one of such issue. Its hard to keep it open as there is no action-item we can track on the project's side.
So I will close this issue for now. Feel free to re-open the issue after you have provided the live cluster info as listed above at least. Using the recent release of the controller.
Thanks.
/close
@longwuyuan: Closing this issue.
What happened?
In my project i need rewrite one path in ingress, so i looked at documentation: https://kubernetes.github.io/ingress-nginx/examples/rewrite/
My ingress:
another Ingress specification:
Rewrite works fine, access to reg services too. HOWEVER When there is rewrite target annotation i can access even
foo.bar.sk/regSomething/url
. If i disable rewrite target annotation,foo.bar.sk/regSomething/url
is not accesible, like it should not be, because its not specified in Ingress.Made some digging and found out that when rewrite annotation is applied, generated nginx configuration file looks like this:
And when no rewrite annotation is applied generated config looks like:
What did you expect to happen?
After rewrite-target annotation in one ingress rule other ingress rules in namespace should stay unchanged.
How can we reproduce it (as minimally and precisely as possible)?
https://foo.bar.sk/apple => returns "apple" https://foo.bar.sk/ba => returns "banana" https://foo.bar.sk/banana => returns "banana" since it should not
Kubernetes version
OS version