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

Back in 2022 I wrote a blog post I am in your pipeline reading all your secrets! about how secrets can be leaked in Azure Pipelines. I think it’s time to offset that blog post and have a look at how compliance of all pipelines in a single Azure DevOps Project can be achieved. This is done by using a feature called Pipeline Decorators .

What are pipeline decorators?

In most organizations there are certain required compliance and security policies. For example; to be compliant with corporate policies a static code analysis tool must to be executed on all pipelines before executing the actual pipeline tasks. This is where pipeline decorators come in, pipeline authors don’t need to remember to add that step. We as Azure DevOps Organization owners create a decorator that automatically injects the step into all pipelines during their runtime. Ensuring on an Azure DevOps Organization level that all pipelines are compliant with our organization’s policies.

While this post is outside of my usual topics, I would like to share a solution for an error message which returns just a single search result on Google. I want to share it because it took me some time to figure out what was going on. So in case someone else runs into this issue this post might be helpful.

The Issue

It all started after the network team updated the network to a new public IP. Right after this change all users started to get the error message 400 Bad Request. QWNjZXNzIHRvIE91dGxvb2sgb24gdGhlIHdlYiBoYXMgYmVlbiBibG9ja2VkIGJ5 IHlvdXIgb3JnYW5pemF0aW9uLiA8QlI+PEJSPkNsaWNrIDxhIGhyZWY9Ii9vd2Ev bG9nb2ZmLm93YSI+aGVyZTwvYT4gdG8gc2lnbiBvdXQu (Base64) when trying to access Outlook on the web (OWA) in Microsoft 365.

In my previous post 🚀 Azure DevOps Container Jobs: When Microsoft and Self-Hosted Agents meet, It’s the Best of Both Worlds! 🌐🛠️ you where able experience Azure DevOps container jobs. In this post I am delivering on my promise and explain set-by-step how to build and use your own container with Azure DevOps Container Jobs. Buckle up, and let’s get started!

Target set-up

Lets start by having a look at the target set-up.

Did you know that you can run your Azure DevOps pipeline jobs in a container? It’s a great way to combine the benefits of Microsoft Hosted Agents and Self-Hosted Agents. In this post, I will explain what Azure DevOps Container Jobs are and how you can use them to your advantage. But first, a recap of Microsoft Hosted Agents and Self-Hosted Agents.

What are Microsoft Hosted Agents

Microsoft Hosted Agents are a type of agent in Azure DevOps that are hosted and managed by Microsoft. These agents are pre-configured with certain software depending upon the type of agent (Windows, macOS, or Linux) which can run jobs targeting different platforms. With Microsoft Hosted Agents you trade off control for convenience as they are an excellent choice if you need to quickly scale your operations without worrying about the underlying infrastructure management.

Next to the Get-Command and hte Get-Help cmdlets, there are 3 other cmdlets that are essential for any PowerShell user. In this blog post I will explain my view on why they are essential and provide hands-on examples on how to use them.

Unveiling Object Properties and Methods with Get-Member

The official documentation states: The Get-Member cmdlet gets the members, the properties and methods, of objects. Making it the Swiss army knife for exploring the properties and methods of any object in PowerShell and thus indispensable for any PowerShell user.

With this post I want to share my new GitHub repository -> Starter Kit for an Azure IaC repository . This starter kit is based on best practices, personal experiences, and guidelines for creating and organizing code and resources tailored for Azure infrastructure deployment. While the example itself is based on a combination of Azure DevOps, Bicep and PowerShell, the concepts are applicable to any IaC language and tool combination.

In this post I will share a couple of tips with regards to Secrets Management in your (local) dev environment. Personally I use these to prevent / limit leaking of secrets while developing Azure infrastructure. And I consider them as part of my security hygiene during the development process.

Last year I wrote a series of posts covering the naming convention topic. The perfect azure naming convention covered the Azure resources. The primary concept for this naming convention is that in fact Azure resource names are actually ID’s which cannot be renamed. In this post I want to share a method with which renamable display names can be added.

The Microsoft Cloud Adoption Framework is a comprehensive set of guidelines, best practices, tools, and documentation. But, this comprehensiveness can render the framework complex and potentially overwhelming for individuals and organizations, most notably for those with limited cloud expertise. As an attempt to offset the complexity I created a ready to use quick start backlog for the Design Areas sub-section of the Microsoft Cloud Adoption Framework . Via this blog post I want to share it, explain the composition and guide you on how import it into your own Azure DevOps organization within minutes.

In the previous post Sleep Worry-Free: The best tips for Local Secrets Management I shared the best tips for managing local secrets. In this post I will take Secrets Management to the next level by showing you how to create manage and use secrets securely by setting up a local secure store using PowerShell SecretManagement and PowerShell SecretStore modules.

Modules explained

Since this approach to Secrets Management depends on the two just mentioned modules the purpose of each of the modules is explained next.

In this post I will share a couple of tips with regards to Secrets Management in your (local) dev environment. Personally I use these to prevent / limit leaking of secrets while developing Azure infrastructure. And I consider them as part of my security hygiene during the development process.

Use Case

When you are either building new Azure Infrastructure or debugging an existing configuration you will eventually need to use a secret or a password on you local (dev) environment. The most straightforward approach that is often used is to create a new variable and add the secret as a value to this variable. Effectively (temporarily) hardcoding the secret value into whatever you are working on. The following example sows such an approach, it should be quite familiar to everyone who worked with Azure and PowerShell in the past.

This is the 6th post in the category Azure DevOps Fundamentals of the blog post series on working with Azure DevOps In this post the I will show how to use Library for Azure Pipelines.

Since it much more fun to do research and play with technology in collaboration with others, Wesley Camargo will be covering some of the topics on he’s blog , while other topics are covered by my here. Naturally the all related posts will be referenced between the two blogs.

This is the 5th post in the category Azure DevOps Fundamentals of the blog post series on working with Azure DevOps In this post the I will introduce you to the Azure DevOps Demo Generator tool by using it to create a new Project in Azure DevOps.

Since it much more fun to do research and play with technology in collaboration with others, Wesley Camargo will be covering some of the topics on he’s blog , while other topics are covered by my here. Naturally the all related posts will be referenced between the two blogs.

This is the 4th post in the category Azure DevOps Fundamentals of the blog post series on working with Azure DevOps . In this post the I will demonstrate how to create an Azure Service Connection in an Azure DevOps Project.

Since it much more fun to do research and play with technology in collaboration with others, Wesley Camargo will be covering some of the topics on he’s blog , while other topics are covered by my here. Naturally the all related posts will be referenced between the two blogs.