[stable/jenkins] JNLP port should not be exposed via type=LoadBalancer #1341
Comments
Just an FYI, this should really be top priority because what Helm installs out of the box will be very quickly compromised by this security advisory: https://jenkins.io/security/advisory/2017-04-26/ Attacks are in the wild and will happen within a very short time after installing the jenkins chart: https://groups.google.com/forum/#!topic/jenkinsci-advisories/sN9S0x78kMU |
Fixed in #1385 |
Thanks for reporting this @kensimon!!!! |
@viglesiasce Can this issue be closed? |
I'll go ahead and close this, we've verified on the latest chart version that the port is no longer exposed by default. |
We're running k8s across cluster, and using LoadBalancer on the agent Service to allow communication. If no range is specified, it defaults to
https://github.com/kubernetes/kubernetes/blob/870c0507272d13b67c4beff34685ff674f716a2d/pkg/cloudprovider/providers/aws/aws.go#L3394 |
Update `values.yml` documentation on using 'LoadBalancer' type of Service in a secure way by adding required annotations. This creates an internal LoadBalancer with locked down rules on allowed CIDR ranges via annotations.
Update `values.yml` documentation on using 'LoadBalancer' type of Service in a secure way by adding required annotations. This creates an internal LoadBalancer with locked down rules on allowed CIDR ranges via annotations.
Update `values.yml` documentation on using 'LoadBalancer' type of Service in a secure way by adding required annotations. This creates an internal LoadBalancer with locked down rules on allowed CIDR ranges via annotations.
Update `values.yml` documentation on using 'LoadBalancer' type of Service in a secure way by adding required annotations. This creates an internal LoadBalancer with locked down rules on allowed CIDR ranges via annotations. Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com>
* Fixes helm#1341 -- update Jenkins chart documentation Update `values.yml` documentation on using 'LoadBalancer' type of Service in a secure way by adding required annotations. This creates an internal LoadBalancer with locked down rules on allowed CIDR ranges via annotations. Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com> * bump version, per pull request comments Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com> * fix whitespace lint errors Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com>
Do these annotations |
* Fixes helm#1341 -- update Jenkins chart documentation Update `values.yml` documentation on using 'LoadBalancer' type of Service in a secure way by adding required annotations. This creates an internal LoadBalancer with locked down rules on allowed CIDR ranges via annotations. Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com> * bump version, per pull request comments Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com> * fix whitespace lint errors Signed-off-by: Dan Alvizu <dalvizu@pingidentity.com>
Is this a request for help?: No
Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report
Version of Helm and Kubernetes: Makes no difference
Which chart: stable/jenkins
What happened: Port 50000 (the jenkins JNLP master port) is exposed to the open internet via an ELB when the helm chart is installed on a cluster with an AWS cloud provider
What you expected to happen: The jenkins master port should not be exposed the same way the HTTP port is... since it's configured to launch slaves in the same kubernetes cluster, that service can just be ClusterIP. There should be an option to only expose the HTTP port via type=LoadBalancer while keeping the master port private to the cluster.
How to reproduce it (as minimally and precisely as possible):
helm install stable/jenkins
on an AWS cluster (I'm sure it's the same for any other cloud provider)Anything else we need to know: There's enough configuration options to tune this behavior, but the defaults should not be this insecure.
The text was updated successfully, but these errors were encountered: