Forem: Gurucharan Subramani

Getting Started with LightHouse CI - Part 2

Gurucharan Subramani — Wed, 01 Jan 2020 00:00:00 +0000

In the previous part (Part 1), we learnt about how to get started with Lighthouse CI, what are the different commands available, how to run your first scan and compare the results against a baseline. In this part (Part 2), we continue to look at how to set up a Lighthouse server on Azure so that we can upload the scan results, see trends and compare the scores of your site at different points in time.

Server Command

We ran our scans and we have validated that the scores are above our baseline. You know what would be nice? The ability to see the results on a dashboard with historic data from every scan and ability to link them to a specific commit and build/release in your pipeline. This is exactly what the Lighthouse server enables us to do. To install the Lighthouse server, run npm install @lhci/serverand then run lhci server with the below configuration in place to start the server locally on port 9001 which stores the result in a SQLLite Database.

{
  "server": {
      "port": 9001,
      "storage": {
        "storageMethod": "sql",
        "sqlDialect": "sqllite",
        "sqlDatabasePath": "lhci.db"
      }
    }
}

If you now visit port 9001, you will be greeted with a friendly page asking you to run the lhci wizard command to set-up the server.

Caution: Lighthouse server does not support authentication/authorization now but that is being worked on and so please be aware of the risks here.

Before we get to the wizard part, I’ll show you how to run a publicly available Lighthouse server on Azure. If this whole Azure thing is not important to you, feel free to skip the next bits and head straight over to the Wizard Section or head to the cloud recipes for instructions on running the server on a different cloud.

Lighthouse Server on Azure

There is a docker image available for Lighthouse Server. This means that you can make use of Azure Web App for Containers and pass in configuration as environment variables using App Settings.

Log in to the Azure Portal, create a new Azure Web App for Containers to run the patrickhulce/lhci-server image from DockerHub. The next step is to create a Postgres Database on Azure.

Now that the resources are created, let’s update their configurations

Once the database is created, go to Connection Security and ensure that ‘Enforce SSL connection’ is set to DISABLED and the ‘Allow access to Azure services’ is set to ON. Take a look at the related issue on GitHub to understand why SSL is not supported at the moment.
The next step is to add the below snippet to the application settings. Take note of the Postgres connection string. There is a weird %40 thing going on and also we use the default database called postgres. You can, of course, use a Postgres client to create a new database and use that in the connection string.

[
  {
    "name": "LHCI_NO_LIGHTHOUSERC",
    "value": "1",
    "slotSetting": false
  },
  {
    "name": "LHCI_STORAGE__SQL_CONNECTION_SSL",
    "value": "0",
    "slotSetting": false
  },
  {
    "name": "LHCI_STORAGE__SQL_CONNECTION_URL",
    "value": "postgresql://username%40myserver:password@myserver.postgres.database.azure.com:5432/postgres",
    "slotSetting": false
  },
  {
    "name": "LHCI_STORAGE__SQL_DIALECT",
    "value": "postgres",
    "slotSetting": false
  },
]

Once you have all this configuration in place, you should be able to see the Lighthouse server home page prompting you to run the wizard to set up your project.

Wizard Command

As mentioned earlier, Lighthouse Server does not support any form of authentication or authorization as of now and consequently, there is no project management UI either. To set up a project on the server, run lhci wizard on your command prompt, complete the wizard and take note of the GUID token.

Once you have configured a project on the server, you can update your Lighthouse configuration file as shown below

{
  "upload": {
    "target": "lhci",
    "token": "your-token-xxxx-yyyy-zzzz",
    "serverBaseUrl": "https://myserver.azurewebsites.net/"
  }
}

Upload Command

Now you have all the configuration in place and ready to upload results to your server. You can do that with the lhci upload command. When you run the command, you will get an error message saying Error: Unable to determine current hash with git rev-parse HEAD. Lighthouse CI requires certain metadata before pushing the results to the server and tries to infer that from the git repository. They call this Build Context and you can read more on this from their docs.

To push your results to the server, initialize a git repo, commit your changes and then you can upload your results to the server using the lhci upload command. Once you upload multiple results, you can then compare the scores against two different versions, see what changed and understand general trends in your Lighthouse scores.

Autorun Command

The lhci autorun command combines the healthcheck, collect, assert and upload commands depending on the configuration. I find this very useful and it is nice that this convenient wrapper is available out of the box.

Azure Devops Extension

Right now everything works perfect on my machine but still requires some work to get it running successfully inside my deployment pipelines. All my pipelines are hosted on Azure Devops and so I built an extension that features a custom build and releasetask using NodeJS that helps you run Lighthouse CI inside Azure Pipelines.

You specify the command you want to run, point to the configuration file and the extension overrides the build context with relevant predefined variables available inside Azure Pipelines.

In this 2 part Lighthouse series, you have installed Lighthouse-ci CLI, learnt how to configure it, set up the Lighthouse server on Azure and have a good understanding of the different commands (healthcheck, collect, assert, upload and autorun) that is available to you. Once the results are pushed to the server, you would then compare scores, see trends and compare the scores of your site at different points in time.

Right now, I am happy with all the features available considering that this is still in 0.x.y version. Once the server supports authentication and includes a project management UI, then it is ready for prime time. But overall, looks very good to me.

Getting Started with LightHouse CI - Part 1

Gurucharan Subramani — Wed, 01 Jan 2020 00:00:00 +0000

This blog post shows you how to get started with Lighthouse CI, what are the different configurations and commands available to you and how to run your first scan and compare the results against a baseline that you specify.

Lighthouse CI is a node CLI that has a set of commands that make continuously running, asserting, saving, and retrieving Lighthouse results as easy as possible. Lighthouse CI is made up of 2 components, the node CLI to run the different commands and the node server where results are uploaded and stored for you to compare the scores and see trends of individual metrics.

Getting Started

The easiest way to get started with Lighthouse CI is by installing the node CLI globally on your computer. To do this, run npm install -g @lhci/cli. Once the CLI is installed successfully, you can invoke it and understand the options available to you by running lhci --help. You should now see 6 commands available to you.

Configuration

Each of the individual commands have accept some arguments. Run the help command lhci <commandname>--help to understand what configuration options are available to you. Lighthouse CI uses the YARGS API to read configuration and that means you can pass arguments to the CLI in multiple ways and are read in the below order of precedence.

CLI arguments
Environment Variables
Configuration Files
Default Settings

The GitHub documentation goes into great detail with examples of the different configuration options. Throughout this post, I will be using a configuration file to pass arguments. The JSON file structure has the below format and is called lighthouserc.json and is at the root of the current working directory.

The final configuration file is available in this repository on GitHub.

{
  "ci": {
    "collect": {
      // collect options here
    },
    "assert": {
      // assert options here
    },
    "upload": {
      // upload options here
    },
    "server": {
      // server options here
    }
  }
}

Next, let us take a look at the different commands available to us and what they accomplish and how to specify the proper configuration under the relevant sections of the configuration file.

HealthCheck Command

The first command is the health check. The healthcheck command performs a set of checks to ensure a valid configuration and very useful when setting up Lighthouse CI initially.

Run lhci healthcheck on the command prompt and then depending on the contents of your configuration file, you will see different types of checks being executed. Here is the result of a successful health check.

You should execute the healthcheck multiple times as you build up your configuration to understand what checks are included and how the results differ.

Collect Command

Next and perhaps the most important command is the collect command runs Lighthouse scan the specified number of times on and “collects” the results in a .lighthouseci/ folder relative to the current working directory. Run lhci collect --help to see the different configuration options available and how it maps to the JSON file below.

The collect command allows you to

Run scans on multiple URL’s and also scan each URL multiple times.
Run a puppeteer script so that you can log in to the website and then scan pages that require authentication. Note that you will need to install the puppeteer package from NPM.

{
  "collect": {
    "method": "node",
    "additive": false, // Clean up previous lighthouse runs
    "headful": false, // Headless Chrome
    "numberOfRuns": 3, // 3 runs per each URL
    "puppeteerScript": "./fake-login.js", // Run this script before auditing below URLs'. Usually Login Scripts.
    "url": [
      "https://www.gurucharan.in/",
      "https://www.gurucharan.in/about/"
    ],
    "settings": {
      "config-path": "./light-house-config.js" // Flags to pass to lightHouse
    }
  }
}

With the configuration in place, you can now run lhci collect and if everything is successful, you will see the Lighthouse results inside the .lighthouseci/ folder.

Assert Command

We have successfully run our Lighthouse scans and “collected” our results. The next logical step is to run a bunch of tests that verify that the results meet expectations. As with the other commands, below is a snippet of the configuration file.

{
  "assert": {
    "preset": "lighthouse:no-pwa",
    "assertions": {
      "categories:performance": ["warn", {"aggregationMethod": "optimistic", "minScore": 0.70}],
      "categories:accessibility": ["warn", {"aggregationMethod": "optimistic", "minScore": 0.90}]
  }
}

One thing that needs mentioning is that the assertion operation supports a wide range of configurations. You can test against built-in presets or assert against individual categories of Lighthouse results and even set baselines on every metric in the scan results.

When checking the results of runs against multiple URLs, different assertions can be made for different URL patterns using regular expressions. Definitely take a look at the documentation for the assert operation where other options are documented.

In this example, we run tests against the built-in preset which ignores PWA (Progressive Web App) evaluation. We also assert against said performance and accessibility against a baseline score of 0.70 for performance and 0.90 for accessibility. Since we ran the scan against each URL thrice, we specify optimistic as aggregation method which instructs Lighthouse to take the score that has the highest chance of success.

This post showed the basics of getting started with Lighthouse CI and how to run your first scan and compare results against a baseline. In part 2, we continue to look at how to set up a Lighthouse server so that we can upload the scan results, see trends and compare the scores of your site at different points in time.

Five CosmosDB tools that make you productive

Gurucharan Subramani — Thu, 10 Oct 2019 00:00:00 +0000

Azure Cosmos DB is Microsoft’s globally distributed, multi-model, NoSQL database service. Cosmos DB enables you to elastically and independently scale throughput and storage across any number of Azure regions worldwide. Here are some of the tools that are available to make you more productive with CosmosDB.

1. Cosmos DB Data Migrator

Using the Cosmos DB data migrator, you can import from JSON files, CSV files, SQL, MongoDB, Azure Table storage, Amazon DynamoDB, and even Azure Cosmos DB SQL API collections into a new Cosmos DB instance. The data migrator is open-source and available here. You can build it from source or head over to the releases section to download the tool.

You specify where you want to import the data from

Cosmos DB Data Migrator Import

</figcaption>

You then specify how you want to export the data and more importantly the connection type which is under advanced options. You can read about the different connection policies from the Cosmos DB Docs. If you are behind a corporate firewall, Gateway mode is your best bet. Hit next and wait for the data migration to finish.

Cosmos DB Data Migrator Export

</figcaption>

You can automate these steps via the command-line as well. Head over to the folder where the tool was extracted, open the command line and run dt.exe --help. This launch the console version of the tool with useful help on usage and options on how to invoke the migrator via the command line. Great for automation.

2. Cosmic Clone

Cosmic Clone helps in creation of a backup copy of your Cosmos Collection in few clicks and provides options to perform first of its kind data masking and anonymization tasks on Azure Cosmos DB. This one is open-source as well and you can check this out on GitHub. The stand-out features of cosmic clone is the ability to

Create collections with similar settings(indexes, partition, TTL etc) on target instances
Anonymize data through scrubbing or shuffling of sensitive data.

You choose the source Cosmos DB instance and the target instance, specify what you want to clone and add data handling rules and then wait for the cloning process to complete.

Cosmic Clone Handling Rules

</figcaption>

There is no command-line options to automate this process and more importantly the connection policy is set to TCP which does not play well with corporate firewalls. So, if you are behind a firewall, clone the repo, modify the policy, build and run it.

3. Cosmos Capacity Calculator

This should have been called cost calculator and not capacity calculator. Anyway, you can check out the calculator at this website. The estimate takes into account a lot of different factors when calculating the final cost.

When you sign-in with your email account after ignoring the unverified warning on the sign-in page , more form fields are available and you can specify more details about your workload to get better, more accurate estimates.

Cosmos DB Cost Calculator

</figcaption>

The Save Estimate button just downloads a csv file. I don’t understand why the save estimate button and the ability to specify advanced information is available only when you sign-in. Seriously, What am I missing here ? Otherwise, the cost calculator is a useful tool to estimate costs up-front.

4. Cosmos DB Explorer

I like the Azure Storage Explorer. I can browse the contents of your Azure Storage Accounts, Disks and Cosmos DB instances. But for some reason, I couldn’t get it to play nice with proxy settings at work. It would always fail with a 403 error. I was able to access my storage accounts without any issues.

Cosmos DB errors with Storage Explorer

</figcaption>

I googled around like any good developer and found Cosmos Db Explorer. You can head to the releases section of their github repo and download the latest version or you can choco install cosmosdbexplorer if you have chocolatey installed.

5. Visual Studio Code Extension for Cosmos DB

Nothing beats not having to leave your IDE. The VS Code Extension for Cosmos DB enables you to do just that. The extension features a Cosmos DB Explorer to CRUD documents, collections, databases. There is support for Mongo Scrapbooks which allows you to run mongo commands with rich intellisense. Haven’t tried the scrapbooks yet.

These are my favourite Cosmos DB tools. With these tools, I can explore my data, migrate data, back-up and anonymize the contents of my databases and calculate the estimated cost of running a Cosmos DB instance on Azure.

HanselMinutes-Plus-Plus : How I built a podcast transcription service on Azure in a week

Gurucharan Subramani — Tue, 04 Jun 2019 00:00:00 +0000

This is the story of how I wanted to try out the speech to text offerings from Azure Cognitive Services and eventually ended up building a prototype of a podcast transcription service that automatically transcribes any new episode of your podcast and displays synchronized transcripts alongside your audio making your podcast more accessible.

Transcripts provide multiple benefits for the podcast host as well as the listeners. More importantly, it is the right thing do because it makes your web content more accessible. You can read more about this at Podcast Accessibility.

If you want to see this in action, take a look at Hanselminutes++ (running on free plan on Azure) which is a minimal clone of the popular Hanselminutes podcast with synchronized transcripts.

You can also find the source code on github.

The transcripts for HanselMinutes are Artificial Intelligence powered and is about 85%-90% accurate (rough calculation) and extremely affordable at approximately 1 USD / hour of audio when done.

Story Time

The meeting / conversation transcription showcase from Microsoft Build 2019 was lingering on the back of my head and so I wanted to try it out. Although, the meeting transcription service required custom devices, I liked what I saw with Batch Transcription offerings. I decided to give that a try and this is what followed.

1. Azure Batch Transcription

I followed the docs and created a new Speech Services instances on Standard S0 plan in the West US region. I decided to start making POST requests to the transcription endpoint from the Swagger Page after authorizing the requests with my subscription key.

{
  "recordingsUrl": "<SAS URI of Blob>",
  "models": [],
  "locale": "en-US",
  "name": "Title of the episode",
  "description": "An optional description of the episode",
  "properties": {
    "ProfanityFilterMode": "Masked",
    "PunctuationMode": "DictatedAndAutomatic"
  }
}

I realized that I had to input valid Azure Blob SAS URI for the recordingsUrl field. So, I downloaded a mp3 file from Hanselminutes, uploaded them to storage account with storage explorer, generated SAS URI and made requests.

Every episode of Hanselminutes is 30 minutes long and it took almost the same time to transcribe each episode. I learnt that I can register a webhook where the results will be POSTed once they are completed and avoid constantly polling the API to check if transcription is completed.

Side Comment: I tried transcribing all the Hanselminutes episodes from 2018 and 2019 but there were issues transcribing certain episodes and I have a question on StackOverflow about it. I also have questions about request throttling and support for blob storage that are not clear for me from the docs.

2. Azure Functions

I got my first transcription result and I was happy with what I saw. Now, I wanted to transcribe several episodes and realized that it quickly became a tedious task to download mp3 files, upload to Azure Storage and then fire off transcription requests. My developer brain was screaming out for something like Azure Functions and so it I wrote some.

2.1 Http Triggered Function

Accepts a URL of an mp3 file in the triggering request
Downloads the mp3 file as a stream.
Uploads it to a Storage Account.

2.2 Azure Blob Triggered Function

This function is triggered whenever there is a new blob with an .mp3 extension in the storage account.

Generates SAS URI for the blob
Makes a transcription request to the transcription endpoint

2.3 HTTP Triggered Azure Function

This is the function that receives the HTTP callbacks when the transcription process is completed

Processes the transcription results.
Initially I wanted to simply view the transcripts
Later (when I started to build a Hanselminutes clone) decided to store them inside Azure CosmosDB.

3. Azure Logic App

I still needed links to the audio file for each episode of the podcast. I know I can get that from the RSS Feed and I decided to opt for a no-code solution and use the RSS Connector to parse RSS feeds. Although I say things like no-code solution, the truth is that I wanted to try out Logic Apps. ;) ;)

3.1 A Custom RSS Feed

Hanselminutes is a weekly podcast but I needed a RSS Feed that updates way more frequently and on my schedule. I decided to set up my own RSS Feed with my fork of the Lorem RSS Feed where I have only feed item that regularly updates.

For development purposes, I trigger a check on my fake RSS Feed for updates and when there are updates to my feed, HTTP POST items from Hanselminutes feed to the HTTP triggered azure function. Not pretty, but works for now.

4. Azure Web App and CosmosDB

I searched the internet to see if Hanselminutes already had transcriptions and I only found some broken / outdated links. I’m guessing transcripts existed at one point but they no longer do. This was a good excuse for me to build a minimal Hanselminutes clone with transcriptions. I decided to go with CosmosDB to store transcripts and updated the Azure Function to store results in CosmosDB and built an ASP NET Core Web App that spoke to CosmosDB.

High Level Overview of the Initial Version

Costs

The core transcription service from Azure Cognitive Services costs 1 USD / hour of audio in the Standard Plan.
Azure Storage, Azure Functions and Logic Apps are relatively dirt cheap that you can consider them as free value additions.
I store the transcripts on Azure Cosmos DB which has a complex pricing model and it costs a fair bit with the starting price around 24 USD / month. Continue reading to know how the next version addresses this in the next version.
The Hanselminutes clone is hosted on Azure App Service but if you host a podcast you would already have your own website.

Plans for the Next Version

Clearly, Azure CosmosDB is a major cost barrier and the costs can quickly skyrocket with the popularity of the podcasts. I am considering posting transcription results directly to github instead of storing it inside CosmosDB. This allows the transcripts to be “open source” and take community contributions towards increasing accuracy and more importantly drive the costs down significantly.
The RSS Connector on Logic App was great for a quick start but it has introduced a lot of limitations and ‘code smells’. I have decide to replace the RSS connector with this library.
I plan to provide two separate Azure Functions, one to transcribe new episodes and the other to transcribe episodes from your archive.
The editing experience could also be much better. In fact, it would be great to have a standalone editor running on github pages with the ability to import and edit speech to text results generated by Azure and later accommodate other transcription engines as well. Import your transcript ➡️ Make corrections ➡️ Export. Send a pull request.
The ability to distinguish between speakers would be great but “not today”…[Update 17 June,2019] : Azure Speech Services now supports Speaker Diarization.

I expect the next version to shape up like the picture below and once the project reaches there, the transcription costs will be available at approx 1 USD / hour which is how much Azure Transcription Service cost. The rest of the value add stuff which complements your workflow is available at a paltry budget. No more of that submit your audio file for transcription and we will email you transcripts in 24 hours that you can later add to your website.

High Level Overview of the Next Version

Closing Remarks

It started with me wanting to try out the Batch transcription API on a Saturday morning to see if it was any good. A week’s worth of effort later, I end up here. Although this was a fun side-project, I am quite happy with how this turned out considering the below facts.

Did I know anything about how the internals of speech-to-text Artificial Intelligence magic works ? No.
Forget Artificial Intelligence. I did not know how to implement synchronized scroll by myself. I spent a good 4-6 hours on that before giving up and building on top of the scrollTo Library. Was never good with JS anyway.
The only “original code” that I wrote was the logic to to trigger the scroll of in sync with the audio. That was it. Around 50 lines of javascript. The rest of the code was mostly straight out from the Azure docs.

It has been a fun ride building on the shoulders of the giants and their abstractions and I want to see how far forward I can take this.

How to Improve Your Azure Security with the Secure DevOps Kit for Azure (AzSK)

Gurucharan Subramani — Tue, 30 Apr 2019 00:00:00 +0000

The Secure DevOps Kit for Azure (AzSK) is a free and open source toolkit that checks your Azure resources for operational and security best practices. The kit in it’s core is a Powershell Module that caters to the end to end Azure subscription and resource security needs by checking key areas like

Subscription Security - ARM Policies, RBAC (Role Based Access Control), Security Center Configurations
Resource Security - Https Configurations, Firewall Rules, Key Rotation, Token Expiration, Backup and Disaster Recovery Configuration and many others.

This post helps you get started with the core features of the Secure DevOps Kit by showing you how to

Install AzSK and running your first scan
Understand the scan results.
Push scan results to Azure Log Analytics and visualizing scan results like below screenshot

I have further provided links to the official docs if you want to try out some of the advanced features such as

Customizing the security checks
Azure DevOps (VSTS) and Jenkins integrations to include these checks in your deployment pipeline.
Continuous security monitoring post deployment.

AzSK-Log Analytics

Installing AzSK and Running your First Scan

I am assuming you, dear reader, have basic knowledge of Powershell. In case you need to get started or brush up on your Powershell, the AzSK team have done a fantastic job to help you with this crash course.

Ensure you have PowerShell version 5 or higher installed on your machine. You can check the version of Powershell installed on your machine by running $PSVersionTable on your PowerShell window. Update your PowerShell version if you need to. The update is mostly straight-forward. Google is your best friend here 😊

Powershell Version

Once you have the right version of Powershell installed the next step is that you trust me, copy and paste scripts into your Powershell ISE Window and run them. 😊 The scripts use the new Azure Powershell (Az) Modules extensively. I have included an overview of what the script attempts to accomplish and also in-line comments wherever necessary.

Copy and Paste - Drill 1

Drill 1 involves the installation of The Secure DevOps Kit for Azure. The installation does not need admin privileges and installs the modules for the currently logged in user. The Azure Security Kit relies heavily on the new Azure Powershell (Az) Modules. You can run the below scripts to install AzSK on your machine. The installation might take some time and in the meanwhile, you can take a look at the official setup instructions which contains answers to frequent installation problems.

# Install AzSK
Install-Module AzSK -Scope CurrentUser -AllowClobber -Force

# Display some info about AzSK
Get-InstalledModule AzSK

# Lists all the commands available in AzSK
Get-Help AzSK

Copy and Paste - Drill 2

Now that AzSK is installed successfully, drill 2 involves the below script which helps us to obtain the most value from AzSK by setting up a Log Analytics Workspace to visualize the results.

The script below

Imports AzSK into the current session
Prompts you to login to Azure
Creates a new Resource Group in a subscription of your choice
It then creates a Log Analytics workspace with the AzSK visualizations
Configures AzSK to push the scan results to the newly created workspace

Save the below script in a file called AzSK-setup.ps1. From your Powershell ISE window which you already have open, you can run .\AzSK-setup.ps1 -SubscriptionName "your-subscription-name"

Param
(
    [Parameter(Mandatory=$true)] [string]$SubscriptionName,
    [string]$Location = "East US"
)
$RgName = "AzSK-GettingStarted-RG"

#The script requires Powershell 5 or higher. Imports AzSK in current session.
Import-Module AzSK

Connect-AzAccount

Get-AzSubscription -SubscriptionName "Visual Studio Professional" | Set-AzContext

# Check if a resource group by name "AzSK-GettingStarted-RG" exists
Get-AzResourceGroup -Name $RgName `
                         -ErrorAction SilentlyContinue `
                         -ErrorVariable rgError

if ($rgError)
{ # Resource Group Does not exists. Create a new one.
   New-AzResourceGroup -Name $RgName -Location $Location
}

#Create a Log analytics Workspace if not exists
$LogAnalyticsWorkspace = Get-AzOperationalInsightsWorkspace `
                        -ResourceGroupName $RgName | Select -First 1

if ($LogAnalyticsWorkspace.Count -eq 0)
{
    $WorkspaceName = "AZSK-log-analytics-" + (Get-Random -Maximum 99999)
    $LogAnalyticsWorkspace = New-AzOperationalInsightsWorkspace `
                                -ResourceGroupName $RgName `
                                -Name $WorkspaceName `
                                -Location $Location `
                                -Sku "standalone"
}

#Get Subscription Id
$SubscriptionId = Get-AzSubscription `
                    | Where-Object Name -eq $SubscriptionName `
                    | Select-Object Id

# Setup AzSK View in Log Analytics
Install-AzSKOMSSolution -OMSSubscriptionId $SubscriptionId.Id `
                        -OMSResourceGroup $RgName `
                        -OMSWorkspaceId $LogAnalyticsWorkspace.CustomerId `
                        -DoNotOpenOutputFolder

$LogAnalyticsKeys = Get-AzOperationalInsightsWorkspaceSharedKeys `
                      -ResourceGroupName $RgName `
                      -Name $LogAnalyticsWorkspace.Name `

Set-AzSKOMSSettings -OMSWorkspaceID $LogAnalyticsWorkspace.CustomerId -OMSSharedKey $LogAnalyticsKeys.PrimarySharedKey

Copy and Paste - Drill 3

This is the fun part where we can finally scan our Azure Workloads and compare them against security best practices.

The below script scans a subscription of your choice and all the resources inside it. Running this script shows you the real time progress of the scan results on the console. The subscription scanned can be a different subscription to the one contains the Log Analytics Workspace.
The results are also summarized in CSV, PDF and Json formats in addition to pushing it to the Log Analytics workspace.
The scan also generates fix scripts (doesn’t run them) which can be used to automatically fix failing security controls.

Save the below script in a file called AzSK-Scan.ps1. From your Powershell ISE window which you already have open, you can run .\AzSK-Scan.ps1 -SubscriptionName "your-subscription-name"

Param
(
    [Parameter(Mandatory=$true)][string]$SubscriptionName
)
Import-Module AzSK
Connect-AzAccount # Skip this in cloud shell
# Run this in a new Powershell Window after running previous script

$SubscriptionId = Get-AzSubscription `
                    | Where-Object Name -eq $SubscriptionName `
                    | Select-Object Id

# Sets Location where scan results are stored to current folder.
Set-AzSKUserPreference -OutputFolderPath (Get-Location).Path

# Scan the subscription against Security Best Practices
Get-AzSKSubscriptionSecurityStatus -SubscriptionId $SubscriptionId.Id -GeneratePDF Portrait -GenerateFixScript

# Scan the individual resources against Security Best Practices
Get-AzSKAzureServicesSecurityStatus -SubscriptionId $SubscriptionId.Id -GeneratePDF Portrait -GenerateFixScript

# Resets location where scan results are stored.
Set-AzSKUserPreference -ResetOutputFolderPath

AzSK Scan Results

The AzSK scan results are stored inside a folder called AzSKLogs relative to the current working directory. The .csv file is a good starting point to understand the results. They contain detailed information about the controls scanned, the status, the severity and other details that are self-explanatory. Convert this to a spread-sheet, format it as table, add your excel magic and email this to your boss.

The fix scripts are also generated thanks to the GenerateFixScript argument. Proceed with caution and test the fix scripts before running it against production workloads.

You can head over to the Azure Portal and navigate to the Log Analytics Workspace and see that the scan results are also pushed to the Log Analytics workspace that was configured. It usually takes around 30 minutes on your first scan for the scan results to show up in Log Analytics. The subsequent results show up much faster.

Pro Tip : The built-in visualization of the log analytics shows only the baseline controls for the last 3 days. Base line controls are the most important security controls that ensure a decent basic level of security.

To match the results in the .csv file you have to edit the workspace and specifically modify the queries across every blade and specifically remove the where TimeGenerated > ago(3d) and the IsBaselineControl_b == true parts from the query. You can also add / remove / edit the blades to customize the AzSK Solution for Log Analytics.

AzSK-Edit-Queries

Advanced Features

Continuous Assurance (CA) Mode - This is an Azure Automation runbook that scans your subscription at a scan frequency of your choosing. This greatly help situation where systems are already live and you want to monitor the security posture continuously to avoid security drift.
Continuous Assurance (CA) in Central Scan mode - When you have a large number of subscriptions, you can setup CA in Central Scan mode which provides you the ability to monitor several target subscriptions using a single master subscription that contains the automation runbook. Configuring this can take up a couple of hours and is flaky. Carefully follow these instructions.
Customizing the Security Rules - AzSK also provides a possibility to customize the security controls which helps you to do things such as disable certain controls, change control severity, modify recommendation messages etc. based on your context.
Alerting - Since the scan results are configured to be sent to Azure Log Analytics workspace, you can configure alerts using the Log Analytics API.
CI/CD Integration with Azure DevOps and Jenkins - Running these security scans periodically from a PS console is great but integrating them in your CI / CD pipeline is even better. AzSK provides extensions for Azure DevOps (formerly VSTS) and Jenkins.

AzSK-AzureDevOps

With configurable security policies, auto generated fixes, multiple results formats, CI/CD extension and out of the box Log Analytics dashboards with querying and alerting capabilities, the Secure DevOps Kit for Azure is a must have tool for teams working with Azure to adopt a security first mindset and create secure workloads on Azure.