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.
Related
The use case is a user has a metadata that needs to be encrypted so when they sign-in a protected and stored object "encrypted" will be "checked" to verify the object information coming in plaintext is equal to what is in the encrypted object.
The question is, is it more appropriate in an Azure Key Vault to give each and every user a key with public and private key ability. Or, just use a single key that will encrypt the object that is stored and just un-sign/decrypt the object when it is accessed.
To me, the object is what is necessary to be encrypted and doesn't really relate to how the key is encrypted hence a universal 1 key to many approach.
The other approach makes sense too but I would have to create a hell of a lot of keys in order to facilitate such an approach. Is 1000's or millions of keys resulting in a key per each user appropriate?
What are the advantages or disadvantages of each other.
I think the same practice would apply to JWT token signing.
I think its better to have one key and on a regular basis rotate the key.
For example, like they do in ASP.NET Core Data Protection API (I know you are using node) where they every 90 days (by default) replace the current key with a new one, and the old one is still kept to allow decryption of old data. In .NET they call this the key-ring, that hold many keys.
I did blog about this here.
Also, do be aware that using some SDK's with Azure Key Vault, they try to download all secrets at start-up, one-by-one. That can be quite a time consuming if you have many secrets.
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
I'm implementing Azure Redis Cache in Asp.net Core MVC 2.1 application. I need to set the default key expiration value for all the keys globally. And also I should be able to override the expiration duration on individual keys.
I know we could set expiration on individual keys using IDatabase.KeyExpire method, but I'm looking for some sort of configuration that applies to all the keys.
Note: I'm using default eviction policy(volatile-lru), no changes made to it.
AFAIK, redis does not provide this ability - you'll have to specify automatically expiring keys. Please refer to this article.
When we go to the definition of IDatabase, we could see the following picture the KeyExpire and only specify single key to set expiration other than the KeyExists could set an array of key. So you have to set expiration value for each key.
For more details, you could go to this article.
Are you trying to save by not having to execute the EXPIRE command for each key? If so, the Redis SETEX command which performs the SET and EXPIRE together might help, and you can use a pre-configured expiry value via an extension method / wrapper. StackExchange.Redis uses the SETEX command when using an expiry. For setting an expiry on individual keys, you can use the EXPIRE command.
The Azure Function documentation is clear on using Host and/or Function keys to provide "api key" authorization. However, I can't find anything that indicates if there is a limit on how many keys can be created on a particular function or function app.
I would like to share a unique key with each tenant in a multi-tenant application so I can update or revoke them on a per-tenant basis. However, this approach will only work if I am able to generate hundreds (or potentially thousands) of keys.
Can anyone confirm any known limits on the number of keys that can be generated on a function app?
There aren't any strict limits imposed by the runtime, but we can't make any guarantees that this would be performant at scale.
I am trying to get an understanding of the purpose of signed identifiers when using Shared Access Signatures with Blob storage in Azure. I know that signed identifiers are basically applied at container level and are a named. Furthermore, I know that they provide any Shared Access Policies to be valid for longer than an hour (as opposed to when not specifying a signed identifier). I guess my question is couldn't you just apply a shared access signature at the container level with appropriate permissions and expiry time? Thanks to all that reply.
Okay, I think I get now. So best way to interpret SI's are that they are another level of abstraction for access control at the container level. Furthermore, they allow you to specify how long policies can be applied before they are revoked. In both explicit and SI declaration, revocation is pretty much the expiry time.
So my next question is say for instance I have a policy that has been compromised. How exactly do I immediately revoke or change the policy (being that I've defined this policy in my code; how would I change it without having redeploy code)?
The Signed Identifier is how you reference an ACL on a particular Container. These are required for you to create revocable access to your blobs.
If you create an Expiry Time longer than one hour the Blob Service could possibly return a 400 Bad Request Error, or simply ignore the expiry time and set it to 1 hour.
This is done as part of the platform to ensure that your data is secure.
There is more information about the lifetime of a SAS in the MSDN Library
The main reason for the signed identifier as opposed to explicitly specifying all parameters has to do with security. If for some reason a SAS was created that had all the parameters specified and had a valid HMAC signature, the blob service would honor it. Imagine there was no limit to expiry time. Now, imagine it leaks. In the normal case, it can only do damage for up to an hour. Rememeber, you have specified all the parameters in it, so you cannot change it. If you could specify an unlimited time, it could not be revoked without actually changing your main storage key (that would invalidate the sig and break all existing SAS). The SI gives you one more layer of abstraction to prevent having to roll storage keys.
The signed identifier (or policy as I like to call them) is the way to extend past an hour and still be able to a.) immediately revoke if necessary or b.) immediately change. With the SI, you can change the permissions, you can delete it, you can change the expiry, all of which give you greater control over the life and access of your existing SAS (the ones that use SI anyway).
Actually I've just answered my own question. I can write code to reference the containers in question and clear out the access policies currently set any container.