Securing DevOps Pipelines in Azure: From Code to Cloud

Yogesh Morankar — Mon, 27 Jan 2025 10:58:12 +0000

Introduction

Recent studies show that 62% of organizations have experienced DevOps pipeline breaches due to inadequate security measures.

Securing DevOps pipelines is essential to protect your software delivery process from threats and vulnerabilities. Pipelines act as the backbone of continuous integration and delivery (CI/CD), handling sensitive information like source code, credentials, and access tokens. Without robust security measures, these pipelines become attractive targets for attackers seeking to inject malicious code, steal intellectual property, or disrupt services.

By embedding security into every stage—from code commits to cloud deployment—you mitigate risks like data breaches, unauthorized access, and compliance violations. A secure pipeline ensures your software is not only delivered quickly but also remains reliable, confidential, and trustworthy for end users.

Understanding consequences of unsecured DevOps

Unsecured DevOps pipelines pose significant risks that can compromise the integrity, confidentiality, and availability of your systems. Some key risks include Data Leaks, Unauthorized Access to Pipeline and Artifacts, Supply Chain Attacks etc.

Data Leaks

Sensitive Information Exposure: Pipelines often handle credentials, API keys, and private configurations. Without proper encryption or restricted access, these can be leaked, leading to unauthorized access.
Source Code Theft: Exposed repositories can allow attackers to access proprietary code, intellectual property, or customer data.
E.g. If you are using Default agent machines provided by different DevOps tools like GitHub, Azure then they are more likely to result in Data leaks and other issues. Because these agents are globally distributed and shared across multiple customers/applications, using these agents is Highest Risk.

Unauthorized Access

Compromised Build Systems: Attackers may exploit weak authentication or unpatched vulnerabilities to gain access to CI/CD systems.
Privilege Escalation: Misconfigured roles or permissions may allow unauthorized users to execute actions beyond their intended scope.

E.g. Most of the time we do not treat our self hosted agents as our data storage which results in weak access mechanisms and open surface for cyber attacks. While Designing the DevOps pipelines we should make sure that we consider the Pipelines as part of our application, i.e. its resources should be accessible within the same restricted area as your application and not outside.

Supply Chain Attacks

Injection of Malicious Code: Attackers can compromise build artifacts, inject malicious dependencies, or tamper with code during deployment.
Downstream Impact: Infected pipelines can deploy compromised applications to production, affecting users and linked systems.

By addressing these risks through robust security practices, such as securing credentials, implementing least privilege, and using trusted tools, you can ensure that your DevOps pipelines remain resilient and trustworthy.

What should we do ?

Setup Self Hosted Agent

To avoid these issues with Default Agent Machines, you can use self hosted agents. Most of the DevOps services provide the configuration to add Self Hosted Runners/Agents to the Pipelines.

E.g. Setup a Self Hosted Agent in your environment and use these self hosted agents instead of Public Agents. Here are some references that you can use;

This will help you to run the build & deployment activities from the secure VM’s in your environment instead of Public Agents. This way your data/application/secrets never leave your environment and keep safe on these self hosted agents.

Setup Private Virtual Networks for your Self Hosted Agents

Let me Help you with the Example here;

Figure 2.1 Sample Private Virtual Network For Application with DevOps Agents

In the diagram figure 2.1 above you can see that self hosted agents are deployed in the same Vnet as other resources to avoid any communication over the Public internet. Basically

There are options where you can choose to set up a separate Private Vnet for self hosted agents and peer the network with your application network for access based on the Organizational size and policies. Where only limited traffic is allowed between the peered network.

Again, the purpose here is to keep self hosted agents inside the private networks and use these agents in your pipelines instead of global agents.

Setup Jumpbox to access private networks

When we set up the private networks, there are ways to access these networks like through jumpbox (refer figure 2.2). Jumpbox is the machine through which you can expose an endpoint to connect to these networks for troubleshooting purposes. In cloud there are also services like in Azure we have Bastion Host service for the same purpose.

Setup Network Firewall Rules or Network Security Groups

You can connect to this machine with your user identities with limited access and then you have access to the resources inside the network. We can configure the Firewalls and Network Security groups for securing these jumpbox and hardoning of the network.

Figure 2.3 Sample Network Security Rules for Self Hosted Agent

In the example above figure 2.3, we have a network security group created to allow only SSH connection to the jumpbox, that too specifies inbound IP’s which are organizational IP’s. That means, you can connect to these machines only through your organizational networks and no public access is granted to these machines.

Setup Private Repositories or Private Container Registries to store pipeline artifacts

Supply chain attacks pose a significant risk to DevOps pipelines. Protecting pipeline artifacts, such as OS images and application containers, is critical to ensuring the security of your deployment process.

Steps to Set Up Private Repositories or Container Registries

Choose a Cloud Service:
Select a private repository or registry service. Examples:
- Azure Container Registry (ACR)
- Amazon Elastic Container Registry (ECR)
- Google Container Registry (GCR)
Store Artifacts Securely:
Store your OS images, Docker container images, and other build artifacts in these registries.
Enable Private Endpoints:
Configure the service to use private endpoints to ensure communication occurs over your virtual network (VNet) and not the public internet.
Integrate with CI/CD Pipeline:
Update your CI/CD pipeline to authenticate and interact with the private registry.

Setup environment variables or critical credentials as Secrets and allow access to them only through pipelines with user defined identities or system managed identities. These identities should have limited access to read the repo code or other artifacts that we access in the pipelines.

E.g. Nowadays most of the solutions like Github, Azure, AWS provide options to set up environment variables and secrets.

The major difference between environment variables and secrets is that variables are not masked and printable in pipelines while the secrets are masked and not printable in the pipelines.

Though there are ways to print secrets, which I will say are bad coding practices.

We hope this blog provides a clear understanding of the essential secure practices that can be adopted in your projects. Security is a shared responsibility, and we invite you to share your experiences, insights, or suggestions on this topic. Together, we can learn, innovate, and strengthen our ability to deliver a secure and trustworthy environment for our customers and stakeholders.

Azure – Numino Labs