Azure Insights: Policy for server auditing; Infrastructure as Code; Application Insights logging; Logic Apps

Azure pros share their insights on Policy for server auditing, Infrastructure as Code, Application Insights logging, and Logic Apps.

Auditing servers with Azure Policy

Microsoft senior cloud advocate Thomas Maurer explored how users can extend Azure Policy to guest operating systems of Azure VMs. Before auditing, users must setup a VM extension and enable system identity management. An extension isn't required for Arc connected machines because it is a part of the Arc Connected Machine agent. Within Azure portal, users can assign policy, select a policy definition to implement, and set parameters for Guest Configuration policies. After clicking Review + create, it takes a few minutes for the compliance view to show up.

He shared a command to deploy the extension at scale. He wrote:

If you want to get an overview of your compliance state, you can go to the Compliance page, and you will get an overview of the different assignments and their compliance state. You can also have a more detailed look at the initiative or policy and the definition. You cannot just use the built-in policies and initiatives, you can also write your own.

Microsoft offers built-in definitions, but users can also create their own policy definitions  with JSON definitions. 

The case for Infrastructure as Code

Thomas Thornton discussed Infrastructure as Code (IaC) as a way to eliminate inconsistencies, deploy more rapidly, and boost productivity. IaC offers source control by code reviewing pull requests, testing changes, and build validation configurations.

With an IaC approach, it's possible to make mutable, rapid changes, stop configuration drift, and create multiple environments from the same code base. Thornton also highlighted security, troubleshooting and cost control options.

Failing dependencies and Application Insights logging

Microsoft MVP Tobias Zimmergren explored the role of Application Insights to keep track of exceptions, ingested logs, custom logs, performance, uptime, and dependency failures. It can be an important tool to spot patterns in system data. However, as the number of ingested logs grows users can run into 404 and 409 errors. As a result, scaling up can incur costs, interpreting the data can become more challenging, and setting alerts gets more challenging.

Filtering out requests with an ITelemetryProcessor isn't particularly hard… let's define our ITelemetryProcessor, and tell it to ignore something - in this case, I'm just looking for the dependency of type Azure table and where the success is false; In your scenario, just as the code comments say, you should align this with your workloads and logic for a better fit.

Setting up secure communication between Logic Apps

Karim Vaes explored how to set up secure communications between two Logic Apps. A sender Logic App is seen as a Managed System Identity in AAD. Users need to set an audience scope applying to an application object inside an AAD tenant. He wrote:

This token will then be included in the authorization header (as a JWT token) towards the receiver (LogicApp on the top right). The receiver will validate the JWT token by checking the public keys of the issues (AAD). Next up, it will check if the Issuer and Audience provided match the defined policy. If all is okay, then it will accept the request.

Vaes detailed supporting documentation, setting an audience, and defining IP ranges.