I've taken over a system where a central Windows server uses SSH tunnels to connect to several client servers, which are also Windows-based. Developers use RDP to access the central server, while Jenkins pipelines operate via these SSH tunnels (with key-based authentication, a non-standard port, and IP restrictions) to transfer files and run commands on the client machines. While this setup functions, I don't feel entirely secure; if the central server gets breached, it could jeopardize all the clients. I'm thinking about redesigning it and would love to gather some insights. Some alternatives I'm considering include: a site-to-site VPN (like WireGuard) with proper segmentation, deploying Jenkins agents on each client (using a pull model instead of push), or establishing a bastion hub separation. All servers currently run Windows, but clients are open to using Linux. What would be a more secure and standard approach in today's environment?
3 Answers
Implementing a proper CI/CD pipeline could be a great improvement. This could help streamline your operations and enhance security.
Are you providing IT management for these clients? It might be wise to set up some kind of Remote Monitoring and Management (RMM) system with step-up authentication for connections. Alternatively, you could rework the data flow: instead of having the central server push commands to all the clients, consider having the clients pull data from you. You might want to explore the ansible-pull model for this.
I recently started at this company, and the existing model was created by someone who's no longer here. I find it fascinating! I hadn't thought about using Ansible since I've mainly worked with it on Linux systems with some form of network connection. Here, we’re only working with Windows machines located in different places with public IPs and firewalls. Thanks a ton for the suggestion!
It seems like you're essentially recreating something like Ansible. You should check if there's a suitable connection plugin that fits your needs, as the default option is SSH.
That's a valid point! My primary goal is to reduce the risk and improve the model, especially since the client's requirements aren't likely to change soon.