Welcome to DevJev.nl: Your Guide to Azure, Cloud Security, and DevOps Mastery

There are many Azure related naming conventions guides but this one is mine! For every 10 engineers and architects asked you will get 10 different replies on such a topic as naming conventions. With this blog post I would like to kick-off a small series of blog posts sharing my view points about Azure related naming conventions. In this post starting with why a proper naming convention is important and the 10 commandments I generally follow when working on a naming convention.

Back when all the Cloud and SaaS offerings where a brand new concept most IT administrators ended up choosing the domain name of a tenant. This choice would be then reflected in the SharePoint Online url and the only way to change it was to create brand new tenant. Either due to the somewhat poor choice from the IT administrators, due to mergers, rebranding or acquisitions some organization ended up with lets say less desirable domain name for their SharePoint URL.
Responding to clients with a “no it is not possible to change that” always bothered me back then. So when I learned that this option is now available (in preview) I immediately decided to try it. Via this post I want to share what I learned testing this option.

Like with the two previous posts Hacking Azure DevOps and I am in your pipeline reading all your secrets! I want to continue to raise awareness and understanding about pipeline security in Azure DevOps. In the previous post I have explained how secure / marked as secret variables are handled during pipeline runtime.
In this post I want to show how an Azure Resource Manager service connection configuration is handled during pipeline runtime. And which sensitive information is exposed through this service connection.
Like I mentioned in the previous posts, without proper security configuration for pipelines this information could be abused by attackers.

Introduction

With this blog post I want to raise awareness and understanding on how secure / marked as secret variables are handled during pipeline runtime in Azure DevOps and how these can be potentially exfiltrated. If proper security configuration is not in place this could potentially be abused by attackers.

Lets move ahead to create different types of variables and try to retrieve their values. By doing so at the end of this blog post it will be clear why it’s not very sensible to give all project team members full access to pipelines. And why in some cases it’s better to set-up private build agents.

Introduction

While this case is not a particularly new one and has been posted by Matt Cooper on devblogs.microsoft.com back in August 2020. I still feel that in relation to the possible data spillage it has not received sufficient exposure and the correct amount of awareness I would have expected. I actually stumbled upon this case by accident when playing with the Azure DevOps Library variables API.

So in this post I want to showcase how a possible attacker can use a compromised developers environment to gain access to almost all the data present in an Azure DevOps Organization. While access of the developers environment in question is limited to just a single Azure DevOps Project.

Introduction

Recently one of our clients has asked if it might be worthwhile to look into GitHub. They are currently using Azure DevOps and are as far as I understand quite happy with it. So, I drew up a short summary of pro’s and cons about GitHub vs Azure DevOps. The response that I got was very enthusiastic. And because of it I decided to share this information here.

Keep in mind that this is not a full in depth comparison of both products but more of a management summary intended to decide if it would be valuable to look into what GitHub can offer a company that is currently using Azure DevOps.