If you are a Developer/Architect using Visual Studio as IDE for your development activities, this blog post will be of your interest. During the Ignite 2021 conference, Microsoft released Visual Studio 2019 v16.9 and v16.10 Preview 1. As part of version 16.10 Preview 1, one of the cool features they introduced is to "Remove Unused References..." for any Projects and Nuget packages that are not in use. At the time of writing this blog post, we have Visual Studio Version 16.10.0 (official release) which includes this new feature. As part of development, we generally get carried away and introduce new Nuget package references to your project and add new references to your Projects. By the end of development, you will not be 100% sure which are not being referenced and unused which means you will leave those unused project references in your application. Now you might be wondering what's the big deal in it since it doesn't harm. The advantage of removing unused project r
Immutable Storage for Azure Blob Storage
- Get link
- X
- Other Apps
Azure Blob Storage provides scalable, cost-efficient storage in the cloud. In general, Blob Storage holds organization data like back-ups, unstructured data, files, etc. With the Immutable Storage feature, it allows storing business-related information in the WORM (Write-Once-Read-Many) state. Immutable storage feature is available in all Azure public regions.
Immutable storage feature is set at the container level through an Access policy. Policies apply to all the blobs in the container, can be applied either for the new or existing container and supports all blob tiers (hot, cold, and archive).
Immutable storage supports two policy type:
- Time-based retention
- Legal hold
Note: Immutable policy type can be applied either through Azure Portal or
Azure CLI. You cannot delete or modify any files within the container
when any one of the policy is enabled on the container.
Immutable storage - Policy type |
Time-based retention
If you enable a Time-based retention policy all blobs in the container will
stay in the immutable state for the duration you define as part of the policy.
The retention interval value should be within the range of 1to 400 years. By
default, the time-based retention policy will be created in an unlocked state.
It's always recommended policy must be in a locked state. The maximum number of edits for locked policy to change retention time interval is 5. In terms of the Audit feature for this policy maximum of seven time-based retention policy audit logs are retained for a locked policy. Once you enable the locked policy it can't be deleted or reversed.
Note: If a time-based retention policy applied to an existing container, the effective retention period for the existing blob will be from the time of its
creation.
Time-based retention policy |
Legal hold
When the retention interval is not known or clear, users can set legal holds. Each legal hold policy needs to be associated with one or more tags. Tags are used as a named identifier to categorize and describe the purpose of the hold.
Legal Hold policy |
To retrieve the list of tags associated with the container of Legal hold
policy run the following command
az storage container legal-hold show --account-name $storageaccountname --container-name $containername
Legal hold tags |
Popular posts from this blog
Tidy up - Unused Project and Nuget package reference using Visual Studio 2019
If you are a Developer/Architect using Visual Studio as IDE for your development activities, this blog post will be of your interest. During the Ignite 2021 conference, Microsoft released Visual Studio 2019 v16.9 and v16.10 Preview 1. As part of version 16.10 Preview 1, one of the cool features they introduced is to "Remove Unused References..." for any Projects and Nuget packages that are not in use. At the time of writing this blog post, we have Visual Studio Version 16.10.0 (official release) which includes this new feature. As part of development, we generally get carried away and introduce new Nuget package references to your project and add new references to your Projects. By the end of development, you will not be 100% sure which are not being referenced and unused which means you will leave those unused project references in your application. Now you might be wondering what's the big deal in it since it doesn't harm. The advantage of removing unused project r
Swagger UI for Azure Function v2 & v3 APIs
In this blog post, we will see how to setup Swagger UI for Azure Function APIs in v2 and v3. Now you might be wondering why Swagger? Swagger is a language-agnostic specification for describing REST APIs, it also referred to as OpenAPI. Swagger UI offers a web-based UI that provides information about your REST APIs service. Prerequisites HTTP trigger Azure function provisioned or created in C# Azure DI enabled on Azure Function, for more details refer here with relevant package version installed based on Azure Function version. Integrating Swagger UI into our Applications 1. Install the appropriate package based on the Azure Function version which you are dealing with from the below table. Unfortunately, it's not a single package for both versions due to Azure function v3 because v3 makes use of ASP.NET Core 3.1 which introduces a new serializer System.Text.Json (STJ) out-of-the-box. Azure Function Version Nuget package v2 AzureFunctions.Extensions.Swashbuckle v3
Authenticate Azure Functions - API Keys
In this blog post, we will see one of the ways to secure your Azure Functions using API keys. Security plays a key role as part of SDLC (Software Development Life Cycle) doesn't matter whether it's exposed to the client/public or even if it's internal. There are multiple ways to secure your Azure Functions like API Keys, Certificate, API Mgmt, App Service Authentication, etc. If you are new to the Cloud and Azure Functions but want to make a start with minimal effort and less setup of Infrastructure, then API Keys is the ideal choice. Azure Functions allows you to secure HTTP-triggered functions by API access key in the request. As part of creating new Azure Functions, we can select the Authorization Level enum value. If we set the Authorisation level to Anonymous, no security applied which means no authentication applied for the endpoint. Authorization Level - Function By setting the Authorisation level to Function each Azure Functions require a specific API key to Auth
Comments
Post a Comment