In previous blogs, we’ve explored how an internal development platform allows your development teams to build faster, easier, cheaper, and more securely. Now BRYXX is taking the next step — automating and securing the resource plane of the platform, without using SSH. A bold move? Perhaps. But it’s one that makes the seemingly impossible possible.
This idea took center stage at a recent roundtable discussion with CIOs and CEOs. One BRYXX customer flagged a major concern: combining SSH with Ansible felt downright unsafe. Why? Because it means opening SSH on all servers from a single point with admin access. In response, his company had switched to Puppet — a solution that renders SSH redundant.
So let’s perform a thought exercise. How do you go about setting up something like that? How do you completely disable direct SSH access to your servers? And why on earth would you want to? Because it turns out that you can achieve more that way, with less effort and more security. We’ll come back to this in a moment.
How do you go about it?
Using Puppet, you can build an internal development platform that includes both a developer plane — for fast and secure development — and a resource plane, which safely opens up your servers and other infrastructure to internal users. The result is that all interaction with the infrastructure takes place through that platform, including the central collection and visualization of logs via tools such as Splunk.
There’s no need for direct access to individual servers to consult logs, execute commands, or implement major changes. All of this can happen via the Puppet master or through configuration management code — never manually. And every automatic action is logged, so you’ll always be able to track exactly who did what and when.
Achieve more with less
Picture this: tracking an incoming package might currently mean having four or five remote shells open across different servers. But with the BRYXX platform, all the relevant data for the entire process is available at a glance via the log aggregator.
Yes, you’re giving something up — you can no longer log in to your servers manually. But the point is that you don’t have to do that anymore. You can achieve more with less effort and with a much smaller attack surface because we’ve drastically limited the attack routes hackers can use to penetrate and hop from server to server.
Is this really doable?
Absolutely. With the right tools, you can disable SSH and RDP entirely, as long as you provide a good alternative. Even on the Puppet server, you no longer have to activate SSH, not even to bridge the gap between IT and OT, for example.
But aren’t you simply creating a different single point of failure this way? No, not necessarily. Puppet can be set up with high availability and a failover. Of course, you’re shifting the risk somewhat, but with the right role-based access control you can limit that risk considerably as users only have access to what they really need. And permissions are managed through a secure Active Directory.
Even if hackers managed to get hold of a developer’s credentials, they could only do what that specific developer is permitted to do. Logging in to the Puppet master via SSH just isn’t possible. And even if the hackers succeeded, every action would leave a trail.
What if it goes wrong?
Then there’s always a break-the-glass procedure — an emergency mechanism that temporarily enables SSH access so you can do what needs to be done.