I'm curious about the security implications of not using SSH-based automations for our server deployments. My boss is quite firm about not allowing SSH keys for CI tools like GitLab CI to perform deployment tasks, but everywhere I look, SSH automation seems to be the norm. I'm trying to understand the viewpoint on this and wonder if there are better alternatives that ensure security while still being effective for deployments. I know threat modeling is essential, but I'd love to hear a mix of opinions on this topic from a broad range of experiences.
6 Answers
SSH automation is pretty common and safe if done correctly. Proper key management is critical, and you can always implement measures like IP whitelisting to limit access. However, many recommend exploring alternatives that don't rely on SSH at all, such as infrastructure as code tools like Terraform for seamless deployments and better security when set up properly. It's all about weighing the pros and cons based on your environment's needs.
Your boss's approach has merit. A pull model is certainly more secure since it keeps your CI/CD systems away from direct access to production environments, limiting the risks from potential breaches. Moreover, many professionals advocate for using tools like AWS CodeDeploy or even HashiCorp Vault for better secrets management and deployment strategies.
SSH is often used in multiple automation tools, including Ansible. The key is to ensure you’re using strict protocols and that your keys are managed properly. If you have to stick with SSH, consider setting up strict firewalls and limiting IP access for your CI tools to further secure your deployments.
For managing traditional Linux servers, consider solutions like 'ansible-pull,' which allows the server to run scripts locally and pull configurations from a git repository. It reinforces security by minimizing the need for direct SSH access. It's crucial to understand why your boss is hesitant about using SSH keys—perhaps it relates to a specific vulnerability they're concerned with. If you know that, you might be able to suggest alternatives like using a private runner with a vault for key management, reducing exposure if GitLab gets compromised.
Honestly, it seems like your boss might be misunderstanding potential risks. Compromising GitLab can be a problem, but pushing or pulling code both create vulnerabilities if not managed correctly.
True, and maybe they just heard something from a security meeting without fully understanding the implications.
Another option is to use baked images and cloud-init. With a good config management system like Chef, you can have servers pulling configurations instead of having them pushed, which could reduce the need for SSH. Once you get the hang of it, you might find that this leads towards immutable infrastructure and simplifies your deployment process.
That's easier said than done, especially if you're managing on-prem servers. The cloud makes this much more straightforward.
Many folks argue against SSH for CI/CD due to the risk of access if GitLab's compromised. It's true, managing SSH keys can lead to weaknesses if not handled properly, like shared keys that never expire. That said, moving to a pull model, where machines fetch their updates, could add a layer of security without losing functionality. Innovations like container orchestration (Kubernetes) might help, as they use API calls without needing direct SSH access.
I'm curious how the target environments would get notified for pulls in this scenario? Like, how do you bridge that gap?