iptable firewall rules for go.cd

[pan...@mammoth.io]

I would like to secure the go-cd deployment in a VPN. It should be acessible  from a few whitelisted ip addresses of

a) agent machines
b) web acess through vpn
c) anything needed for github auth.

It should not be accessible from anywhere else. Do  we have any recommendation on iptable firewall rules for this?

A related question is that does any part of go-cd run as a docker container. I noticed a few iptable rules for docker. I am not sure if it is residual from any other experimentation or is a requirement for go-cd.

Warm regards.

Pankaj

[Chad Wilson]

Hi Pankaj

For incoming connectivity from web clients and agents, GoCD only requires a port for HTTP access to be opened. Generally in order to secure a GoCD deployment (VPN or not) you first need to configure it for TLS; which means fronting it with a reverse proxy, TLS terminating load balancer or cluster ingress etc. Generally this would mean you only need to open whatever port/host you have proxying HTTPS GoCD traffic through to GoCD itself.

If you are planning to keep using HTTP without TLS (not recommended, but possible) you'd just need to open port 8153 for incoming by default (or change the cruise.server.port to a different port of your choice and open that).

If you are also asking about required outgoing connectivity it probably varies too much depending on what you are doing with GoCD to comment.

I'm not sure what you are referring to regarding iptable rules related to Docker. GoCD server and agents can run inside containers or Kubernetes if you'd like (or mix and match), but this is your choice. Jobs/tasks running on GoCD agents may need to run/launch containers themselves depending on the needs of your users, however containers/Docker aren't intrinsic to the design of GoCD itself and I can't think of any special firewall requirements related to that.

-Chad

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/b60dcef5-5bba-4d51-b371-014c14c8f724n%40googlegroups.com.

[pan...@mammoth.io]

Hi Chad,

Thanks for these clarifications. I wanted to eliminate exactly these possibilities. This is then something else with my machine configuration. I am digging into it. As of now, I am able to connect to our go deployment, do GitHub sign in, etc, but somehow agents are seeing a timeout connecting to go-server. This happened after I played some bit with the iptables. I would dig more.

-Pankaj

[Sriram Narayanan]

On Sun, Apr 17, 2022 at 10:28 PM 'pan...@mammoth.io' via go-cd <go...@googlegroups.com> wrote:

Hi Chad,

Thanks for these clarifications. I wanted to eliminate exactly these possibilities. This is then something else with my machine configuration. I am digging into it. As of now, I am able to connect to our go deployment, do GitHub sign in, etc, but somehow agents are seeing a timeout connecting to go-server. This happened after I played some bit with the iptables. I would dig more.

Just checking:

Are the agents able to resolve the server by name (in case that is how you are pointing the agents to the servers)? If not, then there might be a DNS issue.

From a different machine, is an agent able to connect to the server?

Just FYI, GoCD agents check with the server at a per-defined time interval and the server then assigns the agent the job to run (a collection of tasks). If an agent is registered with the server but has not contacted the server in some time, then the "Agents" tab on the GoCD dashboard shows the agents in " Lost Contact" mode.

 

-Pankaj

On Sunday, April 17, 2022 at 2:12:12 PM UTC+5:30 Chad Wilson wrote:

Hi Pankaj

For incoming connectivity from web clients and agents, GoCD only requires a port for HTTP access to be opened. Generally in order to secure a GoCD deployment (VPN or not) you first need to configure it for TLS; which means fronting it with a reverse proxy, TLS terminating load balancer or cluster ingress etc. Generally this would mean you only need to open whatever port/host you have proxying HTTPS GoCD traffic through to GoCD itself.

If you are planning to keep using HTTP without TLS (not recommended, but possible) you'd just need to open port 8153 for incoming by default (or change the cruise.server.port to a different port of your choice and open that).

If you are also asking about required outgoing connectivity it probably varies too much depending on what you are doing with GoCD to comment.

I'm not sure what you are referring to regarding iptable rules related to Docker. GoCD server and agents can run inside containers or Kubernetes if you'd like (or mix and match), but this is your choice. Jobs/tasks running on GoCD agents may need to run/launch containers themselves depending on the needs of your users, however containers/Docker aren't intrinsic to the design of GoCD itself and I can't think of any special firewall requirements related to that.

-Chad

On Sun, Apr 17, 2022 at 7:46 PM 'pan...@mammoth.io' via go-cd <go...@googlegroups.com> wrote:

I would like to secure the go-cd deployment in a VPN. It should be acessible  from a few whitelisted ip addresses of

a) agent machines
b) web acess through vpn
c) anything needed for github auth.

It should not be accessible from anywhere else. Do  we have any recommendation on iptable firewall rules for this?

A related question is that does any part of go-cd run as a docker container. I noticed a few iptable rules for docker. I am not sure if it is residual from any other experimentation or is a requirement for go-cd.

Warm regards.

Pankaj

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/b60dcef5-5bba-4d51-b371-014c14c8f724n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/658e99e3-c788-4e8b-ba31-397e32ba914an%40googlegroups.com.

[pan...@mammoth.io]

I have figured out that this is not an issue with go.cd. This is more to do with VPN and NAT requests out from AWS NAT gateway. Working on resolving this in the right areas. To your point, yes, I did notice that another go agent in a different network was having a consistent connection.

Warm regards,

Pankaj