I want to introduce key rotation to my system but for that reencryption is needed. It would be nice to do it reactively on some event, trigger etc., but I can't find anything like that at google documentation.
After a rotate event, I want to reencrypt data with the new key and destroy the old one.
Any ideas, how to achieve this goal?
As of right now, the best that you can do is write something that polls GetCryptoKey on regular intervals, checks to see if the primary version has changed, and then decrypts and reencrypts if it has.
We definitely understand the desire for eventing based on key lifecycle changes, and we've been thinking about the best way to accomplish that in the future. We don't have any plans to share yet, though.
When you rotate an encryption key (or when you enable scheduled rotation on a key), Cloud KMS does not automatically delete the old key version material. You can still decrypt data previously encrypted with the old key unless you manually disable/destroy that key version. You can read more about this in detail in the Cloud KMS Key rotation documentation.
While you may have business requirements, it's not a Cloud KMS requirement that you re-encrypt old data with the new key version material.
New data will be encrypted with the new key
Old data will be decrypted with the old key
At the time of this writing, Cloud KMS does not publish an event when a key is rotated. If you have a business requirement to re-encrypt all existing data with the new key, you could do one of the following:
Use Cloud Scheduler
Write a Cloud Function connected to Cloud Scheduler that invokes on a periodic basis. For example, if your keys rotate every 72 hours, you could schedule the cloud function to run every 24 hours. Happy to provide some sample code if that would help, but the OP didn't specifically ask for code.
Long-poll
Write a long-running function that polls the KMS API to check if the Primary crypto key has changed, and trigger your re-encryption when change is detected.
Related
AWS SecretManager Read and Write concurrency.
If I am writing new secret value to a secret and if at the same time read is performed,
does the read call waits for he write calls to complete?
Or read will retrieve some invalid or intermediate value of the keys stored inside the secret?
By default, the GetSecretValue API returns the version of the secret that has the AWSCURRENT stage. It also allows you to fetch older versions of a secret by specifying the VersionId. Versions are also immutable and if you call PutSecretValue you create a new version.
You won't get partial versions here - the label AWSCURRENT will only be switched to the new version once the update is complete. Everything else would result in a terrible user experience.
I've created users with API Keys in a cloudformation yaml file. We want to renew one API Key but an API Key is immutable so has to be deleted and regenerated. Deleting an API Key manually and then hoping that rerunning the cloudformation script is going to replace it with no other ill effects seems like risky business. What is the recommended way to do this (I'd prefer not to drop and recreate the entire stack for availability reasons and because I only want to renew one of our API keys, not all of them)?
The only strategy I can think of right now is
change the stack so that the name associated with the API Key in question is changed
deploy the stack (which should delete the old API Key and create the new one)
change the stack to revert the 1st change which should leave me with a changed API Key
with same name
deploy the stack
Clunky eh!
It is indeed a bit clunky, but manually deleting it, will not cause cloudformation to recreate the API key, since it has an internal state of the stack in which the key still exists.
You could simply change the resource name of the API key and update the stack, but this will only work if you can have duplicate names for API keys, which I doubt, but I could not find confirmation in the docs.
This leaves the only way to do it, in two steps (if you want to keep the same name). One to remove the old key, and a second update to create the new key. This can be achieved by simply commenting the corresponding lines in the first step and subsequently uncommenting them for the second step, or as you suggested, by changing the name of the API key and then changing it back.
I have a requirement to build a basic "3 failed login attempts and your account gets locked" functionality. The project uses AWS Cognito for Authentication, and the Cognito PreAuth and PostAuth triggers to run a Lambda function look like they will help here.
So the basic flow is to increment a counter in the PreAuth lambda, check it and block login there, or reset the counter in the PostAuth lambda (so successful logins dont end up locking the user out). Essentially it boils down to:
PreAuth Lambda
if failed-login-count > LIMIT:
block login
else:
increment failed-login-count
PostAuth Lambda
reset failed-login-count to zero
Now at the moment I am using a dedicated DynamoDB table to store the failed-login-count for a given user. This seems to work fine for now.
Then I figured it'd be neater to use a custom attribute in Cognito (using CognitoIdentityServiceProvider.adminUpdateUserAttributes) so I could throw away the DynamoDB table.
However reading https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-dg.pdf the section titled "Configuring User Pool Attributes" states:
Attributes are pieces of information that help you identify individual users, such as name, email, and phone number. Not all information about your users should be stored in attributes. For example, user data that changes frequently, such as usage statistics or game scores, should be kept in a separate data store, such as Amazon Cognito Sync or Amazon DynamoDB.
Given that the counter will change on every single login attempt, the docs would seem to indicate I shouldn't do this...
But can anyone tell me why? Or if there would be some negative consequence of doing so?
As far as I can see, Cognito billing is purely based on storage (i.e. number of users), and not operations, whereas Dynamo charges for read/write/storage.
Could it simply be AWS not wanting people to abuse Cognito as a storage mechanism? Or am I being daft?
We are dealing with similar problem and main reason why we have decided to store extra attributes in DB is that Cognito has quotas for all the actions and "AdminUpdateUserAttributes" is limited to 25 per second.
More information here:
https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html
So if you have a pool with 100k or more it can create a bottle neck if wanted to update a Cognito user records with every login etc.
Cognito UserAttributes are meant to store information about the users. This information can then be read from the client using the AWS Cognito SDK, or just by decoding the idToken on the client-side. Every custom attribute you add will be visible on the client-side.
Another downside of custom attributes is that:
You only have 25 values to set
They cannot be removed or changed once added to the user pool.
I have personally used custom attributes and the interface to manipulate them is not excellent. But that is just a personal thought.
If you want to store this information, and not depend on DynamoDB, you can use Amazon Cognito Sync. Besides the service, it offers a client with great features that you can incorporate to your app.
AWS DynamoDb appears to be your best option, it is commonly used for such use cases. Some of the benefits of using it:
You can store separate record for each login attempt with as much info as you want such as ip address, location, user-agent etc. You can also add datetime that can be used by pre-auth Lambda to query by time range for example failed attempt within last 30 minutes
You don't need to manage table because you can set TTL for DynamoDb record so that record will be deleted automatically after specified time.
You can also archive items in S3
Will KMS automatically generate new key versions after a while if I don't do it manually? If I create a key and use it for encryption (and not specify rotation period or next rotation time), will the same key last forever without creating new versions?
I remember reading it will do it automatically somewhere in the documentation a few days ago and now I can't find that page.
There's no obligation to do rotation. If you don't specify a rotation schedule, your key won't change unless you manually rotate it.
If you do use rotation (either automatic or manual), old key versions will be available for decryption indefinitely unless you delete them.
The page you cannot locate may be Key rotation | Cloud KMS Documentation | Google Cloud Platform.
From my "Security Credentials", I can NOT create any more key pairs for my CloudFront setup.
I can only see my existing 2 key pairs and my deleted one. The "create" link is not present.
Do you have a reason for that?
How can I create key pairs without using this interface?
How can I bring back the feature to create key pair from that interface?
It's not possible to have more than two key pairs available for use at any one point in time, see Access Credential Rotation:
[...] you can have two credentials in an Active state at any point in time
so you can rotate them without impact to your application's
availability. The AWS Security Credentials page displays the current
state of each of the credentials you can rotate. The possible states:
Active—Can be used to secure requests to AWS.
Inactive—Can't be used, but can be moved back to the Active state.
Deleted—Can never be used again.
The first sentence is actually a bit misleading, insofar it applies to key pairs in the Inactive state as well, because these can be activated again.
As soon as you delete an inactive key, you will be able to create a new one.