-
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
Support removing NET_BIND_SERVICE permission #12199
Comments
This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The 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 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 |
@longwuyuan: Closing this issue. In response to this:
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 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.
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 |
I don't understand what you mean by this
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. |
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
Is there a link to previous discussion, if the topic I mentioned above has been discussed before? |
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:
***@***.***>
|
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:
> ***@***.***>
>
|
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? |
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:
***@***.***>
|
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
The text was updated successfully, but these errors were encountered: