I have added below properties to arm template (link) to create storage accounts and encrypt them with customer managed keys.
"keySource": "Microsoft.Keyvault",
"keyvaultproperties": {
"keyname": "xxxx",
"keyversion": "xxxxxx",
"keyvaulturi": "xxxxxxx"
}
But when I try to create this resource I get
"Missing pre-requisites to enable EncryptionAtRest/Customer Managed
Key for this storage account."
The reason is the storage account service principal(managed idendity) is not having access to the encryption key in Azure key vault. You cannot give the access in advance until storage account (service principal - managed idendity) is created.
But I see that the storage account managed identity is not created automatically. It is created at the time when we enable the encryption.
I have faced this too, MS doc and this answer were helpeful.
Here is why this is happening actually ( from the MS doc ) :
Choose a managed identity to authorize access to the key vault
When you enable customer-managed keys for a storage account, you must specify a managed identity that will be used to authorize access to the key vault that contains the key. The managed identity must have permissions to access the key in the key vault.
The managed identity that authorizes access to the key vault may be either a user-assigned or system-assigned managed identity, depending on your scenario:
When you configure customer-managed keys at the time that you create a storage account, you must specify a user-assigned managed identity.
When you configure customer-managed keys on an existing storage account, you can specify either a user-assigned managed identity or a system-assigned managed identity.
Related
I'm using a "user managed identity" with the "AcrPull" role to allow my app services to pull images from my Azure container registry. I currently have the ID of this user managed identity defined in my Terraform config in plain text but I'm wondering if it's considered sensitive and I should have it as a secret instead. I know the service principal ID is not necessarily sensitive but the managed identity has no secret to go with it so it seems much more powerful on its own...
I currently have the ID of this user managed identity defined in my Terraform config in plain text but I'm wondering if it's considered sensitive and I should have it as a secret instead.
No it is not. Managed Identities are specifically designed to take away the burden to have any secret at all. The identities can only be used to enable Azure resources to communicate with services that support Azure AD authentication. So, if someone somehow does know the principal ID it can only use to grant or restrict access between azure resources. It cannot be used to gain access to the resource by the person himself.
I'm used to use GCP's secret manager. There, we can create a secret and give a specific READ permission for one specific service account.
I mean, let's say we create a secret ABC and a service account "getsecretaccount", I can give the read permission for this SA called getsecretaccount to access the ABC secret. This getsecretaccount will not have access to any other secret there.
Can I achieve this scenario in Azure Key Vault?
Thx!!
Authorization
Key vault offer two different Authorizations: older Vault access policy and newer Azure role-based access control
Vault access policy
BrunoLucasAzure already explained how this works. Personally I don't recommend using vault access policy unless you have some specific reason to use it:
resource re-deployment will reset existing authorization defined in key vault properties. ref: https://learn.microsoft.com/en-us/azure/templates/microsoft.keyvault/vaults?pivots=deployment-language-bicep#resource-format
passing [] to accessPolicies will clear access policy list
passing null or not using accessPolicies in template will generate error
of course you can read value of accessPoliciesbefore re-deployment and then re-use existing value when re-deploying resource. TBH that kind of hacks should not be required by resource.
For more information: https://docs.microsoft.com/azure/key-vault/general/assign-access-policy-portal
Azure role-based access control
Azure role-based access control based key vault authorization uses Azure RBAC assignments for key vault data layer access control.
There is multiple ready-made RBAC roles for key vault data layer:
Key Vault Administrator
Key Vault Secrets Officer
Key Vault Secrets User
Key Vault Reader
etc
Documentation only mentions thins Azure RBAC for key vault also provides the ability to have separate permissions on individual keys, secrets, and certificates
=> you can add RBAC roles into individual key/secret/certificate
Note that key/secret/certificate must be created before you can add RBAC to it.
For more information: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli
The answer
You can use both methods:
if you use older vault access policy, you need to create one key vault per service principal
if you use RBAC based access control, you can manage access control on individual secret level
if you have 1 azure vault with multiple secrets and you create an access policy for a user and select permission like "get" and/or "list", that user will be able to see all secrets under that vault. no option for separated permission per individual secret
Azure Key Vault is a cloud service that enables the secure storage and access of secrets and keys. Your Verifiable Credentials service stores public and private keys in Azure Key Vault. These keys are used to sign and verify credentials.
https://learn.microsoft.com/en-us/azure/active-directory/verifiable-credentials/verifiable-credentials-configure-tenant
How can we find our Public and Private key for verifiable credentials?
I can see Recovery, Signing, and Update key in my Key Vault used for VC.
• Recovery, signing, and encrypting are various key management and cryptographic operations that are needed to be selected while creating an access policy for the said user selected thus limiting the scope of operations that can be performed by the keys, secrets and certificates issued by that user.
Similarly, the private key and the public key of the verifiable credential cannot be accessible by the ‘USER’ as the user has delegated that authority to the application registered in Azure AD with the permissions ‘VerifiableCredential.Create.All’ and this application registered in Azure AD has been granted API permission for the API Verifiable Credential Request Service. Thus, the private key is generated and is with the service principal of the Azure resource which issues a ‘Verifiable credential’ through the registered Azure AD application to create a key, secret, or a certificate in the Azure keyvault.
• While the public key is with the key, secret or certificate generated in the Azure key vault thus, completing the nexus of secure communication through the concerned application hosted. Thus, in this way, just based on RBAC (Role Based Access Control) and the ensuing access policy actions created in the key vault, you can create secure communication through the web app without exposing the private and the public keys.
For more information, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/active-directory/verifiable-credentials/verifiable-credentials-configure-issuer
We are managing our customers' azure subscriptions using Microsoft Partner Centre >> and using a username I create a new Azure Vault for a customer>> but when I tried to create a new Secret inside the Azure Vault , I got this error:-
The operation "Set" is not enabled in this key vault's access policy.
now when I access the Key Vault >> Access Policy >> I am unable to add the login username which I used to create the Key Vault inside the Key Vault access policy, where I am only able to add the office 365 admin:-
so any advice why i am able to create a new Key Vault, while i am unable to add Secrets inside it?
When you create the Key vault, you should add the CSP access policy rather than normal access policy.
After you click on it, you can specify CSP security group (it has shown the steps to get the group id).
Then the CSP user can create secret in this key vault after it's created.
If I give owner access to an app on subscription level, do I still need to add the app on access policy in key vault so that the app can retrieve the secret value from azure key vault through http GET method?
The answer is yes, if you use the Vault access policy permission model.
However, the answer is no, if you use the Azure role-based access control permission model - but then you would have to assign an appropriate RBAC role since the Owner role would not have access.
Reference: Provide access to Key Vault keys, certificates, and secrets with an Azure role-based access control (preview)