You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I did not see the word immutability in any ticket. Azure has immutability available in Storage and Backup Vaults.
Immutability to Azure Storage Accounts is the protection of the data from alteration until the end of a term. At the end of the term it takes no action on the data other than to leave it in place and not protect it anymore.
SUMMARY
Account Level Immutability for Azure Storage Accounts can only be enabled at Creation and therefore needs to be available in the module. It needs to at least be able to enable in an unlocked state. After creation this setting is visible under DATA PROTECTION and Access Control in a storage account of the type STORAGEv2
ISSUE TYPE
Feature Idea
COMPONENT NAME
azure_rm_storageaccount
ADDITIONAL INFORMATION
from my research...
Azure Storage accounts have immutability controls at several levels (StorageV2 required)
Storage Account Level. It can only be enabled at account creation and the policy applies to all within.
The container level. This can currently be set. It can be applied at any time after a container is created (set under Access Policy for the container)
Individual Blob level (set under Access Policy for the blob).
Outside of disabled, immutability has two levels:
unlocked. Policies that have been set can be changed or deleted at any time. Their existence will give you a feel for what issues you may encounter.
locked. Once you lock immutability it cannot be undone. The Blob, Container or account will not be depletable until all objects have expired from the policy.
Immutability can apply to versioning and have implications if you make a lot of changes. I personally am not interested in that right now.
How do you tell Immutability is enabled.
you can see it at the at the storage account level.
Container level I have not checked, any container queries require access to the container.
Blob level... Azure lets you see what blobs have immutability by using their "blob inventory". Be aware there is a note that if you have version immutability enabled... the blob inventory won't give you any immutability data in reports.
Having immutability enabled will affect other operations you have already built. For instance, one blob in a container with an access control policy that has not expired will prevent removal of the container. An Account Level rule could lock and prevent alteration of anything within.
Reference commands
These are the sample controlling commands from CLI. The later can be set after creation. State cannot be changed from LOCKED
--enable-alw
The account level immutability property. The property is immutable and can only be set to true at the account creation time. When set to true, it enables object level immutability for all the containers in the account by default.
Accepted values: false, true
-immutability-period --immutability-period-in-days
The immutability period for the blobs in the container since the policy creation, in days.
--immutability-state
Defines the mode of the policy. Disabled state disables the policy, Unlocked state allows increase and decrease of immutability retention time and also allows toggling allow-protected-append-write property, Locked state only allows the increase of the immutability retention time. A policy can only be created in a Disabled or Unlocked state and can be toggled between the two states. Only a policy in an Unlocked state can transition to a Locked state which cannot be reverted.
Accepted values: Disabled, Locked, Unlocked
seeing storage settings
These are the property lines that can be projected.
// storage account account immutability details
// NOTE: FILTERED to 50 records. Adjust accordingly
Resources
| where type == 'microsoft.storage/storageaccounts'
| join kind=leftouter (ResourceContainers
| where type=='microsoft.resources/subscriptions'
| project subscriptionName=name, subscriptionId) on subscriptionId
| project
name,
subscriptionName,
immunity_with_versioning_enabled = properties.immutableStorageWithVersioning.enabled,
immunity_state = properties['immutableStorageWithVersioning']['immutabilityPolicy']['state'],
immunity_period_since_creation = properties['immutableStorageWithVersioning']['immutabilityPolicy']['immutabilityPeriodSinceCreationInDays'] ,
immunity_protected_append_writes = properties['immutableStorageWithVersioning']['immutabilityPolicy']['allowProtectedAppendWrites']
| limit 50
The text was updated successfully, but these errors were encountered:
I did not see the word immutability in any ticket. Azure has immutability available in Storage and Backup Vaults.
Immutability to Azure Storage Accounts is the protection of the data from alteration until the end of a term. At the end of the term it takes no action on the data other than to leave it in place and not protect it anymore.
SUMMARY
Account Level Immutability for Azure Storage Accounts can only be enabled at Creation and therefore needs to be available in the module. It needs to at least be able to enable in an unlocked state. After creation this setting is visible under DATA PROTECTION and Access Control in a storage account of the type STORAGEv2
ISSUE TYPE
COMPONENT NAME
azure_rm_storageaccount
ADDITIONAL INFORMATION
from my research...
Azure Storage accounts have immutability controls at several levels (StorageV2 required)
Outside of disabled, immutability has two levels:
Immutability can apply to versioning and have implications if you make a lot of changes. I personally am not interested in that right now.
How do you tell Immutability is enabled.
Having immutability enabled will affect other operations you have already built. For instance, one blob in a container with an access control policy that has not expired will prevent removal of the container. An Account Level rule could lock and prevent alteration of anything within.
Reference commands
These are the sample controlling commands from CLI. The later can be set after creation. State cannot be changed from LOCKED
--enable-alw
The account level immutability property. The property is immutable and can only be set to true at the account creation time. When set to true, it enables object level immutability for all the containers in the account by default.
Accepted values: false, true
-immutability-period --immutability-period-in-days
The immutability period for the blobs in the container since the policy creation, in days.
--immutability-state
Defines the mode of the policy. Disabled state disables the policy, Unlocked state allows increase and decrease of immutability retention time and also allows toggling allow-protected-append-write property, Locked state only allows the increase of the immutability retention time. A policy can only be created in a Disabled or Unlocked state and can be toggled between the two states. Only a policy in an Unlocked state can transition to a Locked state which cannot be reverted.
Accepted values: Disabled, Locked, Unlocked
seeing storage settings
These are the property lines that can be projected.
// storage account account immutability details
// NOTE: FILTERED to 50 records. Adjust accordingly
Resources
| where type == 'microsoft.storage/storageaccounts'
| join kind=leftouter (ResourceContainers
| where type=='microsoft.resources/subscriptions'
| project subscriptionName=name, subscriptionId) on subscriptionId
| project
name,
subscriptionName,
immunity_with_versioning_enabled = properties.immutableStorageWithVersioning.enabled,
immunity_state = properties['immutableStorageWithVersioning']['immutabilityPolicy']['state'],
immunity_period_since_creation = properties['immutableStorageWithVersioning']['immutabilityPolicy']['immutabilityPeriodSinceCreationInDays'] ,
immunity_protected_append_writes = properties['immutableStorageWithVersioning']['immutabilityPolicy']['allowProtectedAppendWrites']
| limit 50
The text was updated successfully, but these errors were encountered: