Does Azure Key Vault purge expired versions automatically so it does not get returned from get key versions?
Background:
We plan to use Azure Key Vault certificates with a 2 month rotation. So, we will set ValidityInMonths to 2 and RenewAtNumberOfDaysBeforeExpiry to 3 or so. The reason for the short rotation is that it will be used for asymetric signing.
We need to make the public keys available from an API, so we will call get key versions.
My concern is that the number of versions will keep growing every 2 months.
No, the process is not automatic. To permanently delete a secret First a user must delete the object, which puts it into the soft-deleted state. Second, a user must purge the object in the soft-deleted state. The purge operation requires additional access policy permissions.
Note: Soft delete is Enabled by by default.
You can find more information here Azure Key Vault soft-delete overview
Related
Suppose I have this scenario where I created a signed URL to GCP object using the private key of the service account using the following command.
$ gsutil signurl -d 10m <private-key> gs://<bucket>/<obj>
Due to some reasons, I don't want to give this signurl ie., I want to revoke access.
I tried this, by limiting the duration to 0s. But the issue is for every time we run the gsutil signurl command new URL will be generated. Therefore the former one will still be accessible, in my case.
$ gsutil signurl -d 0s <private-key> gs://<bucket>/<obj>
Solutions that I can think of is,
Remove the role of "Storage Object Viewer" to the service account (OR)
Regenerate the JSON private key (OR)
Delete this particular service account.
Kindly assist me if there are any better ways using gsutil to revoke the signed url and correct me if my solutions are apt in this scenario.
You would need to delete the service account key which could have a several minute delay and would also invalidate other signed URLs.
Validation of signed URLs is via the public key and timestamp. If the timestamp has not expired, all that is left is to delete the public key which requires deleting the service account's private key.
In the event that the Signed URL was generated by the Google Managed service account key, then you must delete the service account.
According to GCStorage docs, you have to wait for expiration time or renewing service account. (https://cloud.google.com/storage/docs/access-control/signed-urls#should-you-use)
But those does not meet my requirement. So my workaround is just rename the object. After renaming, the old signed url will immediately not work anymore.
(be aware of performance of rename operation. GCS docs states that it needs to copy then delete which is slow when processing large file. But in practice, looks like GCS just edits the file metadata to rename files in same bucket. I tried rename/move large file (1GB) in same bucket and it's immediate.
Another issue is loosing original filename. I can think of some solutions such as storing original filename in cloud storage file's metadata or you can have a separate database (such as mysql) for mapping original filename to corresponding storage filename.
)
I only see Key Vault Secret rotation but not Key Vault Keys rotation in docs. Create new version and disable the older version is one approach to rotate Azure Key Vault Keys(Cryptography Keys)
Is there any other way to rotate Cryptography Keys in Azure Key Vault Keys?
Whether working with secrets, keys, or certificates, use the full secret/key/certificate ID which includes the version. For keys, if you set the expiration just beyond the time you want to rotate, you don't need to manually disable the key.
So when you generate a new key or version (when using the same key name, it's the same result) it generates a new key ID you can use while the old remains valid until expired. You don't really need two keys unless you need a period of overlap, but you'd need two different key names at max since you should rely on full key IDs with versions for your application.
I also couldn't find official documentation, but I'll pass along the request. You can also always leave feedback on the documentation, for example, requesting key rotation docs on the secret rotation docs to which you referred.
While implementing secure app model, we have stored the refresh token in azure key vault as a secret. While reconsent we delete that refresh token and again put the new refresh token.
Previously in azure key vault soft delete was not mandatory,so things were working fine. Now in azure key vault soft delete is mandatory so when I delete the old secret and set new secret with same name I am getting exception "Secret already present with deleted state".
As a solution now after delete secret I call purgeSecret to permanently delete it, but there is again a new problem.
Before purging we need to wait around 20 seconds so that deletedSecret call works properly else purgeSecret throws exception that "Secret is being deleted". and also to make purge successfull we again need to wait for around 10-15 seconds after purge call.
So total aroung 35 seconds we need to wait before I completely remove the old secret and then only I can set new secret.
As per our requirement, we can not wait this much amount of time, and we can not update the secret.
Is there a solution for this problem?
instead of implementing a wait, can you implement retry in your code logic that handles the exception and then tries again? There will still be a delay, but it shouldn't take 35 seconds to complete.
Im currently implementing a solution where we are going to store secrets once an hour. It will be the same secret that is updated, or rather we will call SetSecret, since UpdateSecret wont allow us to update the value of the secret. Since Seting a secret with an existing name creates a new version of the same, they will all have an expiry date.
The questions i got is as follows:
Are there any native retention logic for versions. Ex, removed after a certain time if expired/Removed when there is x amount of versions?
If not, is there any max count for versions?
Does it count towards some storage limit?
Manually deleting versions is not possible, so a possible solution will ofcource be to sometimes remove the secret. But this is a step i would like to skip since it will add more complexity if native retention of secrets is supported.
Cheers!
There is no native retention logic within key vault and all the versions will remain in key vault.
There is no limit on the maximum number of versions of a particular secret.
No, it will not be counted towards any storage limit as well.
I am met with the following error details when investigating why an Azure encrypted VM backup failed, but the link provided with the error (https://learn.microsoft.com/en-in/azure/backup/backup-azure-vms-encryption) doesn't resolve my question: exactly which permissions should I grant? All it says is that "The required permissions are prefilled for Key permissions and Secret permissions." Well, that's not a lot of help! I had those permissions already set as default I thought, because I do have lots of backups/snapshots; obviously backups have been working in the past. If I am missing some permission now, is it a Key permission, or a Secret permission? It's not clear! I do see I have the following set up right now:
Key permissions:
Key Management Operations
Get (checked)
List (checked)
Update
Create
Import
Delete
Recover
Backup (checked)
Restore
Cryptographic Operations:
Decrypt
Encrypt
Unwrap Key
Wrap Key
Verify
Sign
Privileged Key Operations
Purge
Secret permissions:
Secret Management Operations
Get (checked)
List (checked)
Set
Delete
Recover
Backup
Restore
Privileged Secret Operations
Purge
Certificate permissions:
Certificate Management Operations
Get
List
Update
Create
Import
Delete
Recover
Backup
Restore
Manage Contacts
Manage Certificate Authorities
Get Certificate Authorities
List Certificate Authorities
Set Certificate Authorities
Delete Certificate Authorities
Privileged Certificate Operations
Purge
Below is the error I see for my backup:
Error Code
UserErrorKeyVaultPermissionsNotConfigured
Error Message
Azure Backup Service does not have sufficient permissions to Key Vault for Backup of Encrypted Virtual Machines.
Recommended Action
Please grant the required permissions to the Azure Backup Service. Refer https://azure.microsoft.com/en-in/documentation/articles/backup-azure-vms-encryption/
Related Links
https://azure.microsoft.com/en-in/documentation/articles/backup-azure-vms-encryption
It looks you missed the Backup permission of the Secret permissions.
In step 6 of the link,
I suppose you give the permissions manually instead of selecting Azure Backup of the Configure from template (optional), if you select it, the permissions will be chosen automatically, that is the The required permissions are prefilled for Key permissions and Secret permissions means.
Here are the steps I took to correct this via http://portal.azure.com (I realize step 6 might be overkill as the Restore permission might be unnecessary here--but hey, this worked):
Search for "Key vaults".
Click on my key vault.
Click "Access policies".
Click "Backup Management Service".
Click on the Key permissions dropdown and uncheck all checkboxes.
Click on the Secret permissions dropdown and choose the Get, List, Backup, and Restore checkboxes.
Click OK.
Click Save back on the "Access policies" screen.
The last step above is important as missing it will cause your changes NOT to be saved. I wrote these steps up and followed them as influenced by a statement I found at https://learn.microsoft.com/en-us/azure/backup/backup-azure-vms-encryption that says, "If your VM is encrypted using BEK only, remove the selection for Key permissions since you only need permissions for secrets." It seems I have BEK--at least that's what my Secret Types are. And indeed, the above worked. The backups began to work again as of July 11th!