Answers: <p>In my experience, the easiest way to do this is to put Jenkins behind an SSL-terminating proxy, such as Apache or Nginx.  You can also configure SSL within Jenkins itself, but I've found that using a proxy is usually a lot easier to set up and manage with regards to SSL.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-02T06:28:24.770Z
Answers: You mention an SSL terminating proxy which is indeed a good way of *securing* the service (as the title of the question implies), but the body of the question refers more to how to configure K8s to allow traffic only from allowed places. I think Karthik's comment is more relevant - perhaps you can merge the two?
Answers: Bruce Becker
Answers: CC BY-SA 4.0
Answers: 2019-08-02T21:27:43.090Z
Answers: Yeah, I agree.  Reading my answer now, I feel like I must've been looking at a different question when writing this answer.  What I wrote doesn't really address OP's question.
Answers: jayhendren
Answers: CC BY-SA 4.0
Answers: 2019-03-04T21:16:32.947Z
Answers: 2019-03-04T21:16:32.947Z
Answers: jayhendren
Body: <p>I have installed Jenkins X on kubernetes. I want to change the default installation and secure the Jenkins url, so that it will be not accessible to the public. </p>
  
  <p>Can I change it to some port, or some way to have a firewall for only few IPs allow to access the Jenkins URL.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-03-05T05:41:50.027Z
Comments: You can use an ingress controller as the entry point into the Kubernetes cluster. That way, you can control the pattern of the URL, port, etc. Another thing that might help is to change the port number of the Jenkins service on K8s. That way, if it is not the default, would be difficult to find out. Hope this helps.
Comments: Karthik Venkatesan
Comments: CC BY-SA 4.0
Comments: 2019-08-02T06:26:39.627Z
Comments: This sounds less like *securing* the service than *obscuring* it. Closing off access except for a whitelist, or changing the port doesn't mean that access to it on those allowed paths will be any more secure. Perhaps change the title of the question? What aspect are you more interested in here?
Comments: Bruce Becker
Tags: <jenkins><kubernetes><jenkins-x>
Title: Secure Jenkins X on kubernetes
UserDisplayName: pioupiou
ThreadText: # Secure Jenkins X on kubernetes
  
  (Asked by: username_0 on 2019-03-04)
  
  I have installed Jenkins X on kubernetes. I want to change the default installation and secure the Jenkins url, so that it will be not accessible to the public.
  
  Can I change it to some port, or some way to have a firewall for only few IPs allow to access the Jenkins URL.
  
  **Tags:** jenkins, kubernetes, jenkins-x
  
  > **Comments:**
  > **username_1**: You can use an ingress controller as the entry point into the Kubernetes cluster. That way, you can control the pattern of the URL, port, etc. Another thing that might help is to change the port number of the Jenkins service on K8s. That way, if it is not the default, would be difficult to find out. Hope this helps.  
  > **username_2**: This sounds less like *securing* the service than *obscuring* it. Closing off access except for a whitelist, or changing the port doesn't mean that access to it on those allowed paths will be any more secure. Perhaps change the title of the question? What aspect are you more interested in here?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2019-03-04. Score: 1
  
  In my experience, the easiest way to do this is to put Jenkins behind an SSL-terminating proxy, such as Apache or Nginx. You can also configure SSL within Jenkins itself, but I've found that using a proxy is usually a lot easier to set up and manage with regards to SSL.
  
  > **Comments:**
  > **username_2**: You mention an SSL terminating proxy which is indeed a good way of *securing* the service (as the title of the question implies), but the body of the question refers more to how to configure K8s to allow traffic only from allowed places. I think username_1's comment is more relevant - perhaps you can merge the two?  
  > **username_3**: Yeah, I agree.  Reading my answer now, I feel like I must've been looking at a different question when writing this answer.  What I wrote doesn't really address OP's question.  
  
  ---
  
  