Hi everyone, welcome to the post-Ignite edition of the Azure CLI blog. Today I will share with you a list of the latest features we released in the Azure CLI supporting various announcements for Microsoft Ignite. However Microsoft Ignite is not just about the major announcements. We also released several important updates to Azure CLI commands based on customer asks surfacing improvements to our core platform services during the Ignite timeframe. Here are some of the exciting announcements and updates.
(NOTE: The Azure CLI commands in the format az command --parameter that are shown below are not intended to be run as is, they only show the key parameters that need to be used for the feature described. Please refer to the documentation links provided to learn how to use the command with all the required parameters.)
Announcements
Azure Arc-enabled Kubernetes is now generally available. This allows organizations to connect, manage and govern any Kubernetes cluster across datacenters, multicloud and edge from Azure. You can reap the benefits of Azure Arc-enabled Kubernetes by connecting an existing Kubernetes cluster to Azure Arc using the az connectedk8s connect command. (Learn more at Connect an existing Kubernetes cluster to Azure Arc)
Azure Resource Mover, which provides portability between Azure regions and is unique to the Azure platform, is now generally available. Azure Resource Mover allows new customers to create applications in existing regions and migrate them upon new region launch or move into regions with availability zones (AZs) if not planned for their region. This service can now be accessed using az resource-mover. We would love to hear your feedback about managing this new service via the Azure CLI. (Learn more at az resource-mover)
Mongo v4.0 server support in Azure Cosmos DB API for Mongo DB is now generally available. This makes it easier for developers using MongoDB v4.0 to migrate to Azure Cosmos DB. Support for Mongo v4.0 can now be leveraged using az cosmosdb mongodb .
Azure Managed Instance for Apache Cassandra is a new service that automates deployment, scaling, and management operations for open-source Apache Cassandra datacenters. It is an ideal service if you want to create hybrid deployments that can extend the capacity in your existing on-premises or cloud datacenters. Customers can now create a managed instance cluster as well as connect to the cluster using az managed-cassandra (Learn more at Use CLI to create Azure Managed Instance for Apache Cassandra cluster)
Azure Cosmos DB Continuous Backup and Point-in-Time is now available in preview. This provides ongoing backups and enables customers to recover and restore data from any point within the past 30 days. To provision an API for MongoDB or SQL API account with continuous backup, you can call az cosmosdb create --backup-policy-type Continuous along with other parameters. You can also use commands with restorable- prefix to enumerate restorable resources; like az cosmosdb mongodb restorable-database list. (Learn more at Use Azure CLI to configure continuous backup and point in time restore ).
Azure Virtual Machine Scale Sets flexible orchestration mode is now available in preview. Customers may now change VM sizes without redeploying their scale set, resulting in greater operational agility. Customers will also be able to mix Spot Virtual Machines and pay-as-you-go VMs within the same scale set to optimize costs. Customers can now create VM Scale Sets in this mode via the Azure CLI using az vmss create --orchestration-mode Flexible. (Learn more at az vmss )
Enterprise friendly security features in Azure Storage
Preventing authorization with shared keys is now in preview. Every secure request to an Azure Storage account must be authorized. By default, requests can be authorized with either Azure Active Directory (Azure AD) credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over Shared Key, and is recommended by Microsoft. So we are more secure by default and require Azure AD to authorize requests, disallowing requests to the storage account that are authorized with Shared Key. For accounts that still need to use shared keys, you will need to explicitly enable this at the account level using az storage account update --allow-shared-key-access (Learn more at Prevent authorization with Shared Key (preview) )
Encryption scopes (preview) enable you to manage encryption at the level of an individual blob or container. An encryption scope isolates blob data in a secure enclave within a storage account. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers. You can create an encryption scope using Microsoft managed keys or customer managed keys (in a key vault or managed HSM) using theaz storage account encryption-scope create --key-source command. (Learn more at Create and manage encryption scopes (preview) ). In addition, you can rewrite a blob with a specified encryption scope using az storage blob rewrite --encryption-scope. This will change the encryption used to protect a blob’s content (Learn more at Encryption scopes for Blob storage (preview) )
Customers who require higher levels of assurance that their data is secure can enable 256-bit AES encryption at the Azure Storage infrastructure level. When infrastructure encryption is enabled, data in a storage account is encrypted twice — once at the service level and once at the infrastructure level — with two different encryption algorithms and two different keys. Double encryption of Azure Storage data protects against a scenario where one of the encryption algorithms or keys may be compromised. In this scenario, the additional layer of encryption continues to protect your data. To set this up, create a general-purpose v2 storage account by calling az storage account create --kind StorageV2 --require-infrastructure-encryption which enables infrastructure encryption and double encrypts your data. (Learn more at Create a storage account with infrastructure encryption enabled for double encryption of data )
IP address related updates to Azure Networking
Azure Public IP SKU upgrade is now generally available. This allows customers to upgrade and retain the same IPs without management overhead or notices to their end customers and now supports the ability to upgrade from Basic to Standard SKU using az network public-ip update --sku Standard. Optionally updating any Basic SKU dynamic IPs using az network public-ip update --allocation-method Static. (Learn more at Upgrade public IP addresses ).
Standard SKU IPs can be zone-redundant (advertised from all 3 zones). This can be configured using az network public-ip create --zone 1 2 3. (Learn more at Public IP addresses in Azure ) You can also indicate if a Standard SKU IP address is "anycast" from multiple regions (Global) using az network public-ip create --tier Global. Note that a "Global Tier" IP is only utilized for the cross-region Load Balancer.
Finally, speaking of IP addresses, Azure ExpressRoute supports IPv6 addresses for peering using az network express-route peering create --ip-version ipv6.
Call to action
We recently blogged about our AI-powered az next command, and are eager to know what you think (Learn more at https://techcommunity.microsoft.com/t5/azure-tools/az-next-ai-powered-interactive-assistant/ba-p/211...)
We also need your valuable feedback on our Azure CLI Beta which is setup for customers to safely try out the breaking changes that shift our authentication to the Microsoft Authentication Library (MSAL) from the Azure Active Directory Authentication Library (ADAL). (Learn more at Azure CLI Beta release notes )
Looking forward to all of your feedback on these updates. Thanks a lot for your continued support!
