I am very excited to see you all in the next Omaha Azure User Group meetup. This time we will speak about the latest advancements and use cases you could apply in your Azure resource authoring toolkit.
As you may know, it is that time of a year when great content will be coming to the town! You could enjoy and learn throughout the month of December, as people behind the #festivetechcalendar will be bringing you lots of new content from different communities and people around the globe.
This year, I have submitted two sessions and have been nicely surprised yesterday. Both sessions have been accepted and I am looking forward to deliver following sessions for the community:
Session # 1: What you need to know about Azure AD security defaults?
Accepted session – “What you need to know about Azure AD security defaults?“
In this session above, we will discuss about how to get started with Azure security on right foot and its challenges. We will focus on importance of a strong Identity and Access in any cloud solution that we are creating for our customers. One simple way to get started is review and adjustment of security default options in Azure AD. We will also look into the set of practices to get you started with Azure AD setup and learn about the benefits of Azure Security Benchmark.
Session # 2: All you need to know about Azure Bicep configurations
Accepted session -“All you need to know about Azure Bicep configurations”
In the second session, we will talk about Azure Bicep – a new language that aims to ease Azure resource authoring and management. This new language comes with a powerful VS Code extension and config file options. In this session, we will unveil dozens of powerful features in our config file to suit your style of coding on VS Code and cheer up our productivity skills. We will apply our fresh skills by creating several Bicep demos in the process.
Conclusion
I sincerely hope that these sessions will spark your interest and I am looking forward to see you all during this event. But most importantly, I hope you could have lots of fun during this festive month.
Stay tuned for more Azure AD, Automation & Security related posts.
In my last posts, I wrote about Azure CL and a Bicep language. The Azure Bicep language, helps to author and manage Azure resources more cleanly and easily on your Azure subscription.
The parameterization of infrastructure deployment files is an important skill where true power of automation and code reuse comes forward. Let’s learn about different parameterization options that you could use in your Azure Bicep deployments. As an example, we will examine the following parameterization options on an Azure Bicep web app deployment file.
βοΈ Using Bicep file as is
βοΈ Using default parameters on your bicep file
βοΈ Simply adding parameters into your command line
βοΈ Using a separate file for parameters, per environment
Option 1: Using Bicep file as is
This first option is the most straightforward way to declare your parameters. However, you would have to enter each parameter name, every time you are deploying the Azure resources.
Following screenshot is a default Bicep web app declaration with parameters. Check the Learn Bicep repo here π
Now, let’s declare an Azure CLI command that will deploy our Azure Bicep file into a Resource group.
# Create a rg-test-deploy RG
az group create -l eastus -g 'rg-test-deploy'
# Option-1: Run deployment file as is
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep
# List all webapps in the subscription
az webapp list --query [].name -o table
Option 2: Using default parameters on your bicep files
The second option will allow us to deploy our Bicep file without entering the default values each time. However, it would require an update on file each time you want to change parameter values π’
Now, we can take the previous webapp-service Bicep file, and add its default values. The updated Bicep file will look like the following screenshot:
Our Azure CLI deployment script would just get a new file name
# Option-2: Run deployment with default values
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-default-param.bicep
# You could also add preflight check with "-c" at the end of each deployment script
Option 3: Simply adding parameters into your command line script
If you would prefer to type parameters and values on a terminal then third option can deliver it for you. That script will look like the following sample:
# Option-3: Run deployment with inline parameters
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep -p location='eastus' appServiceAppName='param-demoapp18' appServicePlanName='asp-param-demo'
Option 4: Using a separate file for parameters, per environment
The last option has multiple advantages over prior options. As you could create separate environment parameters in their own dedicated files and manage them accordingly. For example: You can create a separate param file for “Dev” environment deployments; like in the following screenshot.
Note: parameter files for Bicep language are using a JSON notation, similar to the way how ARM JSON declares parameter files with a following schema.
And our deployment script will look like the following sample:
# Option-4: Run deployment with a separate parameter file
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep -p .\param-files\webapp-service-parameters-dev.json
# List all webapps in the subscription
az webapp list --query [].name -o table
# Clean all resources from RG
az group delete -n 'rg-test-deploy' --yes
Summary
Thank you π for reading this post and learning about four different options to deploy your Azure Bicep files using Azure CLI.
Please check out the Learn Bicep GitHub repo, and follow it. Thanks π π !
Stay tuned for more Azure automation & Azure Bicep posts.
This month we have awesome updates from Azure bicep team that I am happy to share with all of you (Azure community, Deployment Automation, Resource management and Governance geeks π
The following list are August month updates:
Bicep Linter, Snippets, Scaffolding
Right click build
Deployment Stack updates
Bicep roadmap plans (v0.5 and eventually v1.0)
Bicep registry
OCI Artifact standardizations
Module registry functionality
Module Reference Syntax
Parameter Improvement options
Bicep Linter updates
The yellow squiggly lines indicate the Linter violations and complains where best practices are violated. Like, password param should not be checked into the code repository. Another one is using string concat function instead of string interpolation.
Right click build
The right click build on bicep file is a new convince feature that was also added on new build.
You can also use a shortcut keys Ctrl+Shift+B as an alternative way to build your JSON files from bicep files.
Scaffolding feature
This feature also arrived on a v0.4.6 build that provides required-properties to be auto populated to speed up your Azure resource coding. It is derived from a resources swagger spec and auto-populated for you. Yay!
New Code Snippets
You will love to discover that bunch of new snippets has been added.
Just type res- and you will scroll over all those starter boilplet code. Just imagine how much time you will be saving. It is Huge!!!
Bicep Roadmap annoncements
Well, Bicep team annonced that next build will bring the v0.5 and they do target v1.0 by th end of the year. What does it mean is – there will be no API level breaking changes starting from the version v1.0.
What is Next?
Keep tuned for upcoming v0.5 version. The Module registry updates and syntax updates on OCI Artifacts are going to be next Huge things, as they will add into the maturity of this AWESOME tool in Azure!
I hope everyone getting a chance to enjoy the summer and spend some time with loved once.
That said – Azure Bicep team does not seem slowing down, and I love it! New features and capabilities have been added to Azure Bicep product v0.4 version, and we will review those innovations on this post.
What is Azure Bicep?
Azure Bicep is a domain-specific language (DSL) that significantly simplifies the Azure resource authoring. It makes representation of your Azure digital estate concise with clean syntax by adding reliable type safety and code-reuse.
A typical Azure Bicep language code for an Azure storage account declaration will look as simple as the following code below – which basically explains why Bicep is called a DSL.
Why would you need it?
There are number of benefits in using Infrastructure-as-Code approach. Azure Bicep might be the right tool for you to use for Azure deployments, especially if you are trying to modernize and simplify the Azure deployment process.
Let’s look into scenarious where Bicep is the right tool to use:
βοΈ Want to use language native to Azure? βοΈ Looking for fully integrated templates withing Azure platform? βοΈ Looking for fully supported product with Microsoft? βοΈ Don’t want to keep or worry about your resource state information βοΈ Looking to modernize and easy transition from JSON
Well, if your response is YES for above statements/questions then Bicep will be right tool for your solution.
New additions to Azure Bicep in version 0.4
There are numbers of enhancement and features has been added from this release. Let’s look at main Highlights of these features below:
β Linter MVP – The Bicep linter will inspect your code and catch a customizable set of authoring best practices.Β β Deprecated parameter modifiers removed – Strip out deprecated parameter modifier syntax β New code snippets – Suggestion with new code snippets added β Bug fixes – Number of bug fixes added, thanks to community support β Bicep Playground fixes – Playground doesn’t load after breaking change. β Documentation and examples update β Support for List method call on Azure resource references β Support for JSON literal string conversion β Support for using local json templates as modules β Support for object body completion snippets
What is next?
There are still number of milestones in-front of Bicep team, as the versioning # of Bicep project indicates. That said, starting from Bicep version 0.3 you can get an official Microsoft support.
Below is the sneak-pick preview on what is cooking for v0.5 – which is expected to be out sometimes around August month this year.
After updating to the latest Azure CLI (2.22.0) for Windows 10, I am now seeing the same error as others have reported:
Any command such as “az bicep version” is producing the following error:
The command failed with an unexpected error. Here is the traceback and detailed error: type object 'datetime.datetime' has no attribute 'fromisoformat' Traceback (most recent call last): File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 231, in invoke File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 657, in execute File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 720, in _run_jobs_serially File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 691, in _run_job File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 328, in call File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/init.py", line 807, in default_command_handler File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/custom.py", line 3294, in build_bicep_file File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/_bicep.py", line 63, in run_bicep_command File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/_bicep.py", line 152, in _load_bicep_version_check_result_from_cache AttributeError: type object 'datetime.datetime' has no attribute 'fromisoformat'
Is there a temp workaround?
One of the workarounds is to uninstalled Azure CLI 2.22.0 , and then install the prior version 2.21.0. You could confirm 2.21.0 version is working for you by running the same command.
Hope this will be helpful for you, as i faced with this issue hours before my demo to #GlobalAzure 2021 π
I am getting ready bits and pieces of the presentation and demo code for the #GlobalAzure 2021 event.
This is going to be my second year in a row, presenting at this global event, and I am pumped to contribute with two new sessions this year.
Feel free to check out the details of each session and links here .
Session banner for upcoming presentation on Global Azure 2021
WHY bother to transfrom your exising Azure ARM templates into Bicep?
Easy to understand and maintain code for your Azure infrastructure
Day zero support for all resource types & API versions
Nice transparent abstractionΒ for the underlying platform
Awesome Tooling β VS Code extension for Bicep
Deep integration with other Azure Services
Preflight validation β both Bicep/ARM does preflight validation on entire template
Provides high level of confidence that your code is ‘syntactically valid’ before deploying
Support β starting from v.03, Bicep is 100% supported by Microsoft Support Plans
This time, I am looking forward to share level 200 talk and demos, where we will ALL deep dive into challenges of transforming exisiting ARM templates into Azure Bicep.
We will inspect the ARM JSON decompiler, which comes with Azure Bicep and how to make it work your way.
Stay tunes, i hope to see you all during the event!
Hello eveyone, I am very happy to share exciting news with all of you.
Few days ago, i have receieved an email confirming acceptance of my both Azure sessions for the Global Azure 2021 event. I am truely trilled to present on April 16th and 17th following two sesions for eveyone live:
I am looking forward for your participiation, and tune in to learn about latest developments in Microsoft Azure.
In my first session i will share the following new session with you.
Abstract of the presentation as is:
Infrastructure as a Code (IaC) is important strategy to manage your digital estate in any cloud environment. Simplifying management of your infrastructure while re-using code is even better. In Microsoft Azure, we have ARM (Azure Resource Manager) templates that could declaratively define your cloud project infrastructure.
However, it is not easy to author ARM JSON templates and maintain them when your project grows and requires changes. In this demo heavy session, we will introduce the Azure Bicep language and demonstrate how it simplifies authoring ARM templates for your Azure infrastructure. We will author a manageable, readable, and modularized Azure infrastructure code, while using familiar tools.
TheCloudMarathoner π
Please let me know, what topics are you interested in?
As cloudβοΈ journey matures, each company π¨ knows that service requirements and needs will be changing. As cloud providers add new features and products, the new market opportunities and possibilities will rise.
There are several reasons why you would want to pursue the cloud landing zones. Using the start small and expand landing zone, you could get started with cloud adoption at a low-risk pace, and build up the security, governance, and regulatory policies over time.
As a benefit, with “start small and expand” you can use Azure Resource Manager templates and Azure Policy to create a CI/CD pipelines for subscriptions with Azure Blueprints.
As an ongoing improvement effort, you could expand and improve the landing zone with the Cloud Adoption Framework enterprise-scale design guidelines from Microsoft Azure β’
During my journey to become a Microsoft Azure Security professional, I have compiled set of useful resources in addition to the exam materials. These resources do complement cloud and application security with open-source tooling, and a book that is much needed for success.
I am excited to share this with my network and DevSecOps enthusiasts π
WhiteSource Bolt – is a #free developer tool for finding and fixing open source vulnerabilities.
Sqlmap – is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers – http://sqlmap.org/
OpenVAS – Open Vulnerability Assessment Scanner is a full-featured vulnerability scanner. Its capabilities include unauthenticated testing, authenticated testing, various high level and low level Internet and industrial protocols, performance tuning for large-scale scans and a powerful internal programming language to implement any type of vulnerability test. – https://openvas.org/
Recon-ng – is a full-featured Web Reconnaissance framework written in Python. Complete with independent modules, database interaction, built in convenience functions, interactive help, and command completion, Recon-ng provides a powerful environment in which open source web-based reconnaissance can be conducted quickly and thoroughly – https://tools.kali.org/information-gathering/recon-ng
OWASP Glue – is a framework for running a series of tools. Generally, it is intended as a backbone for automating a security analysis pipeline of tools – https://github.com/OWASP/glue
Awesome DevSecOps book. Inspired by the awesome-* trend on GitHub. This is a collection of documents, presentations, videos, training materials, tools, services and general leadership that support the DevSecOps mission. These are the essential building blocks and tidbits that can help you to arrange for a DevSecOps experiment or to help you build out your own DevSecOps program.
#lambhack is A vulnerable serverless lambda application. This is certainly a bad idea to base any coding patterns of what you see here. It allows you to take advantage of our tried and true application security problems, namely arbitrary code execution, XSS, injection attacks and more.
Black Duck is a commercial alternative to WhiteSource Bolt. It helps to manage the risks that come with the use of open source. Black Duck software composition analysis solutions and open source audits give you the insight you need to track the open source in your code, mitigate security and license compliance risks, and automatically enforce open source policies using your existing DevOps tools and processes.
OWASP Honeypot-Project. Goal of the OWASP Honeypot Project is to identify emerging attacks against web applications and report them to the community, in order to facilitate protection against such targeted attacks. Based around the earlier OWASP/WASC Distributed Web Honeypots Project.
Open Source Honeypots That Detect Threats For Free. You could read details on this interesting post.
Note: in noway this presents a complete guide. However, I hope it will guide your project into a more successful DevSecOps state.
I do encouragetoΒ comment and shareΒ your tips and resources here. This will ultimately help every community member to become a better security professional. Thanks!
