How to manage feature flags in ASP.NET Core apps with Azure?
No matter how simple or complex an application is, choosing the right configuration provider right at the start will mak...
But before we start, let’s clear one thing up.
When talking about DevOps in general, typically people immediately think of software development. And of course, this is largely true. But the principles of DevOps and security also apply to infrastructure.
Keep reading, as I will give you some pointers for it here.
If you’re new to Azure DevOps, there’s a useful mind map that details the available functionalities.
The main strength of Azure DevOps is definitely its end-to-end approach. You can use the software to manage a project from beginning to end, starting with Azure Boards, allowing your team to plan their work and see progress on every project as you go, either in a list or Kanban format.
From the security perspective, what you need to look after is Azure Repos. Here is where you can collaborate on code, validate added dependencies, and make sure that code has a good quality.
This is also where you want to protect your code to make sure no unauthorized or dubious changes are made. My colleague and MVP Daniel Krzyczkowski has written a practical guide on this topic – check out the links below to learn how to secure your code in Azure DevOps with manual reviews, limiting merge types, etc.
As a reminder from the previous post, here is what our customers indicate as their top concerns right now:
What can you do about them in the Azure environment?
If you use external dependencies in your projects, it is best to secure them from the early stage – with the “shift left” approach. For example, in GitHub, you can use Dependabot to verify your source code and detect potential vulnerabilities.
Azure DevOps enables installing additional extensions and security tools to allow you to check on your dependencies. Internally, you should regularly check your Dependency Risk Graph to make sure no one inadvertently compromised your code during development.
The key to protecting your dependencies in ADO is securing your code. There is quite in-depth documentation on it. But as usual, it all comes down to the basics: permissions and automation.
Just because you have multiple stakeholders in a project doesn’t mean they all need read & write access. Use the least privilege principle to make sure only developers who really need to access your code can really edit it.
As for automation – you can go so far as to set up automated deployment of a landing zone with Azure Pipelines, so starting a new project will just be a matter of a few clicks. The highlights?
It’s much easier to manage a project when you set it up right to begin with.
I came across a video you may find interesting. It is not about Azure DevOps directly, but about the concept of “secretless coding”. Here Christos Matskas, Identity Expert from Microsoft, talks about how to develop code without including secrets using Azure AD.
This approach can eliminate the problem of credentials to prod environments being valid years later (which happens more often than any of us like to think).
And as a bonus – it’s not limited to Azure, you can use it on-premises as well. Check it out below:
Secretless coding in Azure
This topic could warrant an entire series on its own, and I will keep coming back to it in these e-mails. But if you’re brand new to it, a good place to start is to create a DevOps Center of Excellence.
In it, you can store set rules and policies that everyone working on projects will need to adhere to. Standardizing your processes and sharing lessons from every engagement is the best way to teach everyone involved how DevOps should be practiced at your organization.
The Center of Excellence can basically be a wiki that stores your project policies. It can be as general or as detailed as you like. For example, here is what we keep information about in ours:
And so, you’ll find there a section on Branch policies, specifying:
Keeping all these notes in one place speeds up introducing new people to the project.
Making your processes consistent and measurable by using a shared set of standards is the easiest way to start securing your projects. As for tools – I’ll talk about them a bit more in the next article.
As is the tradition, here are some technical guides for you:
Do you use any of these features? Or maybe something different? Did anything surprise you? Let me know – I will happily discuss it in more detail.
Read similar articles