Over-permissive CI/CD Pipelines are an Unnecessary Evil. Here’s Why.
Many of our customers have been struggling with a similar problem lately, the access permissions that are linked to their CI/CD servers. Development teams want a frictionless path to deploy new code, but giving all CI/CD workstations admin permissions opens them up to risk.
Here’s a deep dive on the topic, and what you can do to fill this common security gap, without adding a blocker to innovation.
Understanding CI/CD Servers
CI stands for Continuous Integration, while CD stands for Continuous Delivery. The CI/CD pipeline makes it easier for developers to quickly introduce new features and updates, in an agile way. DevOps use CI to create a consistent way to build code, and to package and test applications. CD then automates the delivery of these applications to infrastructure environments, such as pre-test, test, or production. As application changes move through the CI/CD pipeline, automation can allow changes to happen very quickly, without creating downtime or delays on the customer-side. This means updates can be pushed weekly, daily, and sometimes even hourly.
This pipeline is one of the areas that you can visualize using Lightspin’s graph-based mapping technology. We regularly find that customers have publicly exposed servers, for example to GitLab in order to give commands, and we can then make recommendations to shore up this vulnerability. That’s relatively simple. However, when it comes to the permissions of CI/CD servers, DevOps often don’t want to deny access. After all, the wide access permissions are part of allowing the speed of innovation, and development teams are regularly and often understandably cautious about putting least privilege or other access rules into place. They may say, “we are aware that it’s over-permissive and may be a risk, but we don’t know what Jenkins or our servers are going to deploy next, and we want to be ready for anything.”
The Risks of Compromised Developer Stations
One additional associated vulnerability that is linked to this problem is the physical workstations of the developers in the company. As each developer uses these servers, which have full admin privileges to deploy new code, if the station is compromised, the attacker can create a new admin asset, launch admin code, and they suddenly have control over your entire cloud environment. This new attack path that comes via the developers workstation has been a traditional blind spot for many of our customers.
The balance is extremely sensitive. DevOps need the speed of change and the ability to innovate freely, but security teams can’t handle the growing risk. Something has to change that can allow security to shift left, and get involved earlier in the CI/CD pipelines, rather than getting in the way.
Reducing the Risk for these Servers, Without Impacting Innovation
For customers who feel that the admin rights are essential for the pace of business, we offer a unique Guardrail solution. A Guardrail works to create rules around server behavior, so that even with admin permissions, certain actions are impossible, and the potential impact on the wider environment is limited. Without changing permissions or enforcing least privilege, here are a few examples.
- The server will be unable to disable multi-factor authentication.
- It will not be able to create new admin assets with admin permissions.
- It will be blocked from deleting any identity objects such as roles.
- It will be unable to change passwords, password policies or security configurations.
This technology is more than just an internal safeguard for your own servers. It also has added benefits when it comes to third-party data sources. Many security teams do not realize that just because the network is private, you’re still sharing pipelines with third parties, including anyone from maintenance, to the team deploying your mobile app. By setting up Guardrails for third parties, you can protect your environment with the best cloud security, without needing to get granular on access permissions.
Dynamic Guardrails: The Lightspin Difference
Of course, at Lightspin we’re known for contextual security, and so our Guardrail solution follows suit. Rather than deploy the same Guardrails generically across all of our customers, and then tweaking based on trial and error, we make intelligent decisions about what your business environment needs, based on context. This allows us to limit what an attacker or a third-party can do specifically for your own network, and protects your assets with granular visibility and insight, not with a wide brush.
On top of this, we continue to advise dynamically moving forward, offering tools such as Drift Detection, so that if anything changes in your cloud environment, you’ll immediately get a notification to update your Guardrail policies.
For security teams, this is the shift left you’ve been waiting for, a method to shore up your defenses early in the process, without adding a blocker to the pace of innovation coming from DevOps CI/CD pipelines.
Any questions? We have answers! Schedule a call with one of our cloud experts.