Support removing NET_BIND_SERVICE permission

[ShuaiShao93]

Some companies have constraints on pod security context that doesn't allow NET_BIND_SERVICE or using low ports. This is already supported by https://github.com/nginxinc/docker-nginx-unprivileged.

#10002

No

[k8s-ci-robot]

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[longwuyuan]

@ShuaiShao93 your asking for a fair and reasonable thing.

But I request you consider the factors that are further from your own requirement. First aspect is that unlike a web application or a database or a message-queue etc., this project is a ingress-controller. That implies administration & infrastructure aspects like allowing traffic from outside cluster to inside the cluster. All browsers and clients that use HTTP & HTTPS use default port as 80/443. So all ingress-controllers have to use NET_BIND capabilities.

This will not change in near future and there are no resources to work on this. You can fork the project and implement your own changes. However the values file of the helm chart of this controller does provide key:value pairs to tweak default ports. Please look up the values file.

/close

[k8s-ci-robot]

@longwuyuan: Closing this issue.

In response to this:

@ShuaiShao93 your asking for a fair and reasonable thing.

But I request you consider the factors that are further from your own requirement. First aspect is that unlike a web application or a database or a message-queue etc., this project is a ingress-controller. That implies administration & infrastructure aspects like allowing traffic from outside cluster to inside the cluster. All browsers and clients that use HTTP & HTTPS use default port as 80/443. So all ingress-controllers have to use NET_BIND capabilities.

This will not change in near future and there are no resources to work on this. You can fork the project and implement your own changes. However the values file of the helm chart of this controller does provide key:value pairs to tweak default ports. Please look up the values file.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ShuaiShao93]

@longwuyuan I get your point, but there are kubernetes services on top of the ingress-controller pods, right? As long as the kubernetes services expose 443, we can forward the request to 8443 of the ingress-controller pods, and users' browsers should never reach the ports of the pods directly.

However the values file of the helm chart of this controller does provide key:value pairs to tweak default ports. Please look up the values file.

I tried to tweak the default ports, but it still requires NET_BIND_SERVICE because of this block: https://github.com/kubernetes/ingress-nginx/blob/main/rootfs/Dockerfile#L71-L76

[longwuyuan]

I don't understand what you mean by this

but there are kubernetes services on top of the ingress-controller pods, right? As long as the kubernetes services expose 443, we can forward the request to 8443 of the ingress-controller pods, and users' browsers should never reach the ports of the pods directly.

Regardless, from all previous discussions, and from all similar issues created, I understand that final decision is NET_BIND will stay. Only option is to fork project.

Apologies that this is not meeting your expectation. I can only repeat that this is infrastructure software and not a webapplication/database.

[ShuaiShao93]

I don't understand what you mean by this

When browser sends requests to a server in a kubernetes cluster, it never directly talks to the ingress-controller pod. Instead it goes through a load balancer service, and the load balancer service forwards the request to ingress-controller pod, so you can see the port and the targetPort can be different in the service below.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
spec:
  ports:
  - appProtocol: http
    name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443
  type: LoadBalancer

from all similar issues created, I understand that final decision is NET_BIND will stay

Is there a link to previous discussion, if the topic I mentioned above has been discussed before?

[longwuyuan]

Will try to search links and post. You can fork project and remove NET_BIND but project can not remove because others need 80/443. Also project has no resources to support and maintain 2 different binaries.

…

On Wed, 16 Oct, 2024, 08:32 Shuai Shao, ***@***.***> wrote: I don't understand what you mean by this When browser sends requests to a server in a kubernetes cluster, it never directly talks to the ingress-controller pod. Instead it goes through a load balancer service, and the load balancer service forwards the request to ingress-controller pod, so you can see the port and the targetPort can be different in the service below. apiVersion: v1 kind: Service spec: allocateLoadBalancerNodePorts: true externalTrafficPolicy: Local healthCheckNodePort: 31447 internalTrafficPolicy: Cluster ports: - appProtocol: http name: http port: 80 protocol: TCP targetPort: 8080 - name: https port: 443 protocol: TCP targetPort: 8443 sessionAffinity: None type: LoadBalancer from all similar issues created, I understand that final decision is NET_BIND will stay Is there a link to previous discussion, if the topic I mentioned above has been discussed before? — Reply to this email directly, view it on GitHub <#12199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGZVWV5IECQFOQC2UZUQJDZ3XJNZAVCNFSM6AAAAABP7R2L4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGYZDMOJTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[longwuyuan]

Also I am not sure if you realise that you described termination on LB and termination on controller. They are different use cases plus we also publish manifests for both use-cases on AWS .

…

On Wed, 16 Oct, 2024, 09:13 Yuan, ***@***.***> wrote: Will try to search links and post. You can fork project and remove NET_BIND but project can not remove because others need 80/443. Also project has no resources to support and maintain 2 different binaries. On Wed, 16 Oct, 2024, 08:32 Shuai Shao, ***@***.***> wrote: > I don't understand what you mean by this > > When browser sends requests to a server in a kubernetes cluster, it never > directly talks to the ingress-controller pod. Instead it goes through a > load balancer service, and the load balancer service forwards the request > to ingress-controller pod, so you can see the port and the targetPort > can be different in the service below. > > apiVersion: v1 > kind: Service > spec: > allocateLoadBalancerNodePorts: true > externalTrafficPolicy: Local > healthCheckNodePort: 31447 > internalTrafficPolicy: Cluster > ports: > - appProtocol: http > name: http > port: 80 > protocol: TCP > targetPort: 8080 > - name: https > port: 443 > protocol: TCP > targetPort: 8443 > sessionAffinity: None > type: LoadBalancer > > from all similar issues created, I understand that final decision is > NET_BIND will stay > > Is there a link to previous discussion, if the topic I mentioned above > has been discussed before? > > — > Reply to this email directly, view it on GitHub > <#12199 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABGZVWV5IECQFOQC2UZUQJDZ3XJNZAVCNFSM6AAAAABP7R2L4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGYZDMOJTGU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[ShuaiShao93]

I wonder if it requires 2 different binaries for this? Is it possible to move this block to an entrypoint.sh file, and only run it when NET_BIND is needed?

[longwuyuan]

I am not a developer so please wait to see if developers have bandwidth to work on this. If you know how to solve this, the faster solution is for you to fork the project and implement your changes. AS far as I know, it requires conditional code paths and there are no resources to work on such changes. Apologies for the situation you are in.

…

On Wed, 16 Oct, 2024, 09:24 Shuai Shao, ***@***.***> wrote: I wonder if it requires 2 different binaries for this? Is it possible to move this block <https://github.com/kubernetes/ingress-nginx/blob/9398c7e747bc74d2ec78be2b4d92ed7dddbb63df/rootfs/Dockerfile#L70-L75> to an entrypoint.sh file, and only run it when NET_BIND is needed? — Reply to this email directly, view it on GitHub <#12199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGZVWVDDSGCJM4M4EDRCJ3Z3XPOBAVCNFSM6AAAAABP7R2L4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGY3TINBSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[longwuyuan]

#3668