Azure Security Kit aka AzSK is a framework that is used internally by Microsoft to control & govern their Azure Subscriptions. While some features are overlapping with Azure Security Center, I find a lot of value in the Kit, mostly in the following areas:
- The attestation module allowing for a full traceability of security controls deviation and justification of why a given control was not respected, which may be very useful in case of internal/external audit
- The CI/CD extensions available on the marketplace. This makes possible to enforce security controls as from CI builds, so very early in the application lifecycle. On top of Azure DevOps extensions, the kit also ships with Visual Studio extensions to provide security guidance as the developer is typing the code.
- An ARM template checker module, available from CI/CD as well as from command line
- A lot of room for customizing control settings, creating organization specific controls, etc.
- It is free, the only costs you might have would be incurred by a few resources (Storage Account & Automation) that are required to use the kit but overall, it is very low.
Today, most companies have at least some workloads in the Cloud but sometimes at the cost of a long and tortuous journey. Here are some guiding principles that I think are important for a successful or at least, less painful journey. The below sequence is more or less logical but activities relating to different principles could be executed in parallel.
1. Understand well your business drivers.
Webhooks are a very convenient way to integrate APIs in general and to call Azure Automation runbooks but while they are very useful and easy to work with, they raise some security concerns. To give a concrete example, if you create a webhook against a runbook that leverages Azure Automation Hybrid Workers, causing this runbook to execute against on-premises machines and/or within your network boundaries, you might want to make sure that the webhook consumer is well eligible to do so. Continue reading
websockets are admittedly not the most commonly used technology although they are very useful in every near “real-time” scenario. The thing is this may have a dramatic impact on the behavior of the Azure Application Gateway, mostly regarding the monitoring aspects.
While the gateway works perfectly with websockets, the associated diagnostics may seem wrong at first, especially when sharing a single gateway across multiple backends, not using websockets. You might indeed end up with charts looking like this:
were you see your latency increasing a lot with frequent peeks..So, if you setup an alert on this latency, you might end up with false positives. When digging further, you realize that this abnormal latency is in fact due to websockets. Continue reading
#ITDevConnections is approaching. Join my sessions where I plan to make some exciting deep dive demos.
I’m going to have 3 talks on the following topics
- Deep Dive into Azure DevOps Custom Extensions (1)
- DevSecOps: Infrastructure as Code: Azure DevOps vs Azure Automation (2)
- DevSecOps: Identity at the Heart of Automation (3)
These three talks can be attended separately or all together since they are somehow linked and part of the same story but you can perfectly afford to attend only one of them and still (hopefully) grasp the overall concepts!
Enough talking, in talk #1, you will learn how to build Custom Azure DevOps Extensions(building/versioning/debugging) and complexity will increase over time since we’ll end up with building custom Service Endpoint Types talking to API Management or to custom APIs through Mutual Authentication, in other words, letting Azure DevOps talking to any backend of yours in different manners.
In talk #2, I have an awesome demo showing how to tackle all the aspects of an application lifecycle from Development to Security & Operations (DevSecOps) with security bits in the picture (MSI, API Management, Azure KeyVault, Azure AD, Network isolation, etc..) and Operational aspects such as Log Analytics & Azure Automation runbooks, everything fully automated and integrated into a single release pipeline. We’ll start from nothing and we’ll have a fully functional application relying on a secure architecture with the basic monitoring blocs in place. I’ll also make a few demos of Azure Automation.
In talk #3, I’ll discuss one of the most challenging topics when it comes to automation: identity. Here again, I’ll show you how to have an end-to-end Enterprise-ready automation of identity-related things (MSI, OpenID and OAuth together with Key Vault). We’ll start simple and we’ll end up with a complex scenario implying user & group assignments.
I’m eager to see you at #ITDevConnections
I have just released the v1.0 of Azure Tools that is an open source initiative available on Github. The idea is to bring a set of tools to bridge VSTS with tools that are typically used by infrastructure and operational teams.
This first version comes with two tasks allowing to call Azure Automation Runbooks from VSTS in a very secure way since the webhook used to trigger the runbook is a one-time one. The other task is to write logs into Log Analytics which has become prominent and is a first class citizen in the Azure monitoring story.
Feel free to try it out and share ideas on what could be useful additions for future releases.
A while ago, I have published a free VSTS extension to automate deployments towards Azure API Management.
I got a rather good feedback and some change requests as well as the involvement of some external contributors on the GitHub Repo. In a nutshell, the purpose of this extension is to bring Azure API Management into VSTS as part of your release lifecyle. Whether you use API Management to monetize APIS or for internal purposes, it is good to associate the release of your backends APIs with their corresponding facade APIs published against the API Gateway. The extension now comes with the following features: Continue reading