Can we use CDN for two different storage account and for different purposes?
This is my current setup.
Storage A: Storage account with static website enabled such as
images, widgets for websites.
Storage B: Storage account with dynamic content such as videos,
audio and images for multiple devices.
I have followed the Microsoft Documentation to create a profile and endpoint.
https://learn.microsoft.com/en-us/azure/cdn/cdn-create-new-endpoint?toc=%2Fazure%2Ffrontdoor%2FTOC.json
Then I created origin and origin group by following this documentation
https://learn.microsoft.com/en-us/azure/cdn/endpoint-multiorigin?toc=%2Fazure%2Ffrontdoor%2FTOC.json
Name for the the first origin and linked to Storage Account A.
Origin1
Name for the Origin Group and linked to Storage Account A
OriginGroup
Then created another origin for Storage Account B and linked to the origin group - OriginGroup
Origin2
The following two different origins are created for the two storage accounts and added to Origin Group - OriginGroup
Origin1 for Storage A
Origin2 for Storage B
I added a custom domain to the endpoint. https://origin.test.io
In summary, there is one endpoint pointing to two different "storage accounts"/"origins" within one origin group. Then the custom domain is created for that one endpoint. It's so that when the custom domain is whitelisted by our customer, it's easier to manage the storage account/origin linked to the endpoint.
I saw the following note on the multi origin documentation. - https://learn.microsoft.com/en-us/azure/cdn/endpoint-multiorigin?toc=%2Fazure%2Ffrontdoor%2FTOC.json
When an origin is created within an origin group, it must be accorded
a priority and weight. If an origin group has only one origin, then
the default priority and weight is set as 1. Traffic is routed to the
highest priority origins if the origin is healthy. If an origin is
determined to be unhealthy then the connections are diverted to
another origin in the order of priority. If two origins have the same
priority, then traffic is distributed as per weight specified for the
origin
Related
When I deploy an instance through the portal, the structure of the FQDN my container is assigned is:
{domain label}.{seemingly random string}.{region}.azurecontainer.io
Deleting & redeploying an identical instance yields the same random string portion, so at least it's not randomized for each deployment, but as this does not conform to the structure defined here in the Azure docs, I'm left without any explanation. Is it a hash? An id? How can this be predicted before deployment?
I believe this is related to Prevent dangling DNS entries and avoid subdomain takeover and ACI DNS name reuse policy:
In order to avoid this, ACI will now allow customers to reuse DNS
names while preventing DNS names from being reused by different
customers. ACI secures DNS names by randomly generating a hash value
to associate with the DNS name, making it difficult for another
customer to accidentally create an ACI with the same name and get
linked to the past customer's ACI information.
There are five "reuse levels" that use hashing to generate a unique DNS name for your container group:
noReuse - no hash, object's DNS name cannot be reused.
unsecure - hash is based on the DNS name only (aka Any Reuse).
tenantReuse (default) - hash is based on the DNS name and Tenant ID.
subscriptionReuse - hash is based on the DNS name, the tenant ID and subscription ID.
resourceGroupReuse - hash is based on the DNS name, the tenant ID, subscription ID and resource group name.
I want to create an Azure Policy for storage accounts. During the creation of a storage account, it will count the number of storage accounts in the subscription which has a specific tag (like env:dev). If the number of this count exceeds 10, It should deny the creation of that storage account.
How I can count the number of storage account which has certain tag inside an Azure Policy declaration?
That is not something you can do using Azure Policy.
Even though the approach seems valid, the count operator is meant to be used with [*] aliases - see official documentation. One could think of scanning Microsoft.Subscription aliases, but running the command az provider show --namespace Microsoft.Subscription --expand "resourceTypes/aliases" --query "resourceTypes[].aliases[].name", what you get as an output is so far not extensive :
[
"Microsoft.Subscription/SubscriptionDefinitions/subscriptionId",
"Microsoft.Subscription/SubscriptionDefinitions/subscriptionDisplayName",
"Microsoft.Subscription/SubscriptionDefinitions/offerType",
"Microsoft.Subscription/SubscriptionDefinitions/etag",
"Microsoft.Subscription/aliases/subscriptionId"
]
Also, the way the policy engine works wouldn't allow you to count the number of instances meeting a particular rule : each ARM component is scanned individually and compared to the rules defined in the policy. You cannot see "all Storage Accounts in a given scope" - each one is scanned without the whole picture being seen at any point. That is why I started with looking if the Subscription object had something like a Resources [*] alias.
I have two storage accounts stinboundclient1 & stinboundclient2 and storage account have initial "stinbound" is common for both. Now inside storage accounts there are containers for each environment (dev,test,prod). Now I have a dev Virtual Machine (DevVM) and it needs access to only "dev" container of both storage accounts. What is the best way we can provide read/contributor access to VM using azure policy or custom role or any other approach?
Please do not suggest manual way of providing RBAC permission to VM bcoz its tedious task to provide each container that access as eventually there will 30-40 clients storage accounts.
Storage Account & Containers:
stinboundclient1/dev
stinboundclient1/test
stinboundclient1/prod
stinboundclient2/dev
stinboundclient2/test
stinboundclient2/prod
DevVM needs access to stinbound/dev*
Similarly Test and Prod need access respective containers::
TestVM needs access to stinbound*/test
ProdVM needs access to stinbound*/prod
It seems to me that what you are looking for is actually what Microsoft calls Attribute-based Access Control (ABAC).
That way, you can grant access to a scope and add a particular condition for this access to be effective on the name of the container, a tag to be present, etc.
This feature is still in Preview though.
my goal is to limit the creation of resource type per owner/collaborator of a specific Resource Group.
Example:
User_Group_XXX accessed by account YYY:
MAX 2 VM - Standard D2s v3
MAX 1 Kubernetes Cluster with 2 node - Standard DS2 v2
NO more than that and NO other type of resources.
How can I include those limits?
this is not possible by definition. Azure Policy looks at individual resource properties, so there is no way to have it do something like that (so check other resources and apply policy based on those resource to a the resource in question).
although, you could easily create a policy to only allow virtual machines\aks clusters.
again, policies cannot be scoped to users
I would like to allow multiple custom defined host headers to access my Azure Blob Storage. Is there a way to do so?
(Case-1: Success, http-200 responsed)
host header (storage.mydomain.com) --> abc.blog.blob.core.windows.net (custom domain: storage.mydomain.com)
(Case-2: Failed, http-400 responsed)
host header (newstorage.mydomain.com) --> abc.blog.blob.core.windows.net (custom domain: storage.mydomain.com)
What should I do if I need to cater "Case-2"?
p.s. I found no way to add more than one custom domain to a blob storage in Azure Management Portal.
I don't believe this is possible. You can only map one CNAME to your storage account and then only use HTTP. Keep in mind that mapping a CNAME on a CNAME won't work either (i.e. foo.domain.com -> mystorage.domain.com -> mystorage.blob.core.windows.net). If you were to do that, storage would see the first one ('foo') and would not be able to resolve which storage account was being accessed.