This week, we’ll cover KMS, Cognito and refresh on the AWS Securities we’ve used to date. I’ll provide the table of links as ever. If you were interested in why we’re going back to Security topics now, here’s a separate page on how we are using the technique of interleaving here.
- KMS (for providing the key infrastructure to encrypt data).
- Cognito (for enabling Authentication and Authorisation to services).
- A consolidation of the security knowledge that we picked up along the way.
As ever, table of contents provided for quick access.
The idea behind KMS is simple enough. It’s a managed service that lets you create Customer Master Keys. Quickly summarised:
- Customer Master Keys are used to create (more accurately generate) data keys.
- Customer Master Keys can else encrypt and decrypt data keys.
- Customer Master Keys never leave KMS
- Data keys are used entirely outside KMS
- KMS doesn’t encrypt using your data keys, you do.
The relationship is illustrated below.
In terms of the exam, I had many questions based around the following theme from the concepts page:
AWS services that integrate with AWS KMS differ in their support for CMKs. Some AWS services encrypt your data by default with an AWS owned CMK or an AWS managed CMK.
You should understand the different kinds of customer master keys to get the bigger picture of ‘human’ and ‘service’ users of keys. It’s summarised in the Customer Master Keys section:
- Customer Managed CMK – you control its lifecycle, you’re the admin.
- AWS Managed CMK – think services like DynamoDB and S3, which as the name suggests, are managed. AWS decides when to administer the keys, for example when to rotate them, not you.
- AWS Owned CMK – an AWS service can use them to protect resources, but they’re transparent to you. They’re also shared across AWS accounts. Since you can’t use them yourself, you’re not charged for indirectly using them.
I created a questions sheet of the core concepts I found useful to cement my understanding. It’s based off the concepts documentation and some exploratory reading/testing of my own. You might find it useful as a ‘search for meaning’ when you look at the overview and play around using the getting started guide.
In term of hands on practice, to pass the exam I didn’t need to go any more in depth than the getting started guide. On the other hand, should you want to learn more (for example for the day job), there’s a workshop on GitHub.
KMS for access control
As I started doing my own research, I thought about breaking the flashcard sets I had into both the core concepts and that of access control. It seemed to make more sense to me to build upon the core idea of KMS first and then to see how that gets used in the context of IAM, which is where access control comes in.
As with any other secured service call, a request gets signed with credentials and the credentials are checked against permissions in IAM. So we need to think about how KMS integrates with IAM next.
As the the authentication sections tells us, we can sign requests to IAM using any of the following IAM identities:
- The AWS root account user (dangerous BUT you should be aware of the concept of a default key policy – they have full access to your keys by default).
- An IAM user – use KMS ‘as a human’.
- An IAM role (do stuff with temporary access keys, especially useful for services to use).
In exam talk, I’d think of this as:
- Understand why the default key policy is useful (and why the root account has it).
- An IAM user might be a better fit for tasks that are carried out as part of the development phase, i.e. a dev running something from a CLI or writing some code as a prototype.
- Once questions get into the realms of deployed services running anything, then I’d be looking at roles since they cover Federated Access, Cross Account Access (e.g. CodePipeline), EC2 running applications and AWS services using KMS.
Next I’d look at authorisation as of course we need to look down who can do what.
This is quote straightforward in as much as you need to review the access control topics under Authentication and access control – the fundamentals are there to get the understanding that I had for the exam. Questions sheet to get you thinking as ever.
KMS Encryption at Rest
I got questions on this in my exam papers, around S3, KMS and Encryption at Rest. What I found was important:
- There is client encryption, whereby you take the responsibility for encrypting your data, e.g. before passing to S3. If you followed my questions sheet, you’ll see there is an important concept called an encryption context.
- There is server-side encryption – where you don’t need to worry about encryption because AWS handles it for you.
- Within server side encryption for S3, there are 3 options – one where S3 does everything, one where you manage the encryption key, and one where AWS manages the data key, but you use KMS to manage the master key.
Ok, so far so good, but remember we don’t want to get good at just ‘exam trivia’. If we look at the S3 example and then compare/contrast with DynamoDB – we see it’s much the same, we have the 3 types of ‘server key’ options but the default is for AWS to own everything.
The one last thing I think might be worth looking at for KMS is how encryption works for EBS. It might cement your understanding to walk through those steps just to understand how a services leverages KMS to get encrypted/decrypted data.
With the understanding of key management under our belt, we can move onto AWS Cognito.
Cognito questions came up a lot according to discussions with my peers at work who had completed the certification, and I got a couple of questions on it when I did my exam.
I’ve put some questions together to focus you when you read through:
We can start with user pools – looks as though we can use more than simply AWS and IAM to say ‘who we are’ – there’s a heap of providers.
Then onto the bigger picture, once you know who I am, how do we get to the services? Start with understanding the exchange (if you’ve used OAuth before then you’ll be good) of an authentication token for a different, opaque token from an identity pool.
I’d go straight to GitHub for this one. It encompasses AWS Cognito and an API Gateway, which came up in practice papers and the exam for me. Personally, I find I learn better when I can see an entire application stack, to understand the moving parts.
From both the tutorial and the diagrams, I’d be trying to understand – how can we mix and match user and identity pool solutions? Can we use Cognito for Authentication but not use an identity pool? Can we do the reverse? What scenarios are there for this? If I can understand the integrations more than the specific details, I can pick up the concepts quicker.
Cognito Sync is the next piece of the puzzle. According to the opening sentence of of the “What Is Amazon Cognito?” page we know that Cognito is for both web and mobile users. So, how do we propagate user data from one platform to another? Enter Cognito Sync.
The starting point is here for what sync is exactly. As an aside, note at the top there’s a little section saying:
If you’re new to Amazon Cognito Sync, use AWS AppSync.
with our critical thinking hat on “if you’re new to” can translate to “what is the easiest way to” when you encounter a question in the exam. Just thought I’d mention.
Going back to sync itself, there’s not a huge amount to it. The idea is:
- You save end user data in datasets containing key-value pairs.
- The data is associated with an Amazon Cognito identity, so that it can be accessed across logins and devices.
- When you sync between Cognito service and an end user’s devices, invoke the synchronize method.
- Each dataset is max size of 1 MB, up to 20 datasets per identity
So where this comes into the exam is when it dovetails with streams and events, where the sync actually has a ‘use’.
Cognito Events and Streams
The idea of streams in Cognito is the same as any other stream, sheer speed of updates, loosely coupled with handlers. When a user syncs data, then the changes gets pushed to a Kinesis Stream. And then it’s up to you to handle that stream. A common pattern might be to push to a Kinesis stream, for even more speed.
In addition, you might have a specific event handler for a change to the synced data. You might want to validate or enrich some data as it is pushed through.
Some questions for Cognito Sync are here, but I’d just understand that for sheer speed, often Kinesis streams are a win.Likewise, if you want to ‘do more’ with a sync, Lambdas are a low cost way of validating/enriching. Hopefully that might help with filtering some exam/answers.
In the exam, another tick for Cognito is that (user) data is both encrypted at rest and in transit – as you can see.
Now, in terms of IAM, a Cognito pool is a resource like any other (i.e it has an ARN), meaning that you can apply policies as you see fit. Remember the point from our earlier IAM study – resource based policies are used when we need cross account access, so Cognito will allow this just like any other resource.
Most important though, is the best practice of using a Service Linked Role with Cognito – if you want to declare no more and no less than you need for Cognito to interact with other services. It will also prevent you from accidentally deleting a policy until the resource has been deleted first.
Finally I’d skim the following topics for an awareness of best practice – just see what’s there.
- Adding Multi-Factor Authentication (MFA) to a User Pool
- Checking for Compromised Credentials
- Adding Advanced Security to a User Pool
Finally, we’ll review what we’ve covered on security up until now. We’ll strengthen our understanding by reviewing how these are all associated.
Review of Security
We sign API requests to prove who we are in IAM, who the principal is. Sometimes the principal is a human, like a developer using the AWS CLI to list the contents of an S3 bucket.
Sometimes the principal is not a human, like an EC2 instance for example. But they still need to interact with other services. In this cases it’s better that the entity assumes a role.
It’s not just EC2, a service like DynamoDB may need to interact with KMS. It’s even better when that system has only the permissions required. No more and no less.
Sometimes the principal is human, but not in IAM, in other words, a federated user. They will have to assume a role too. Temporary credentials for the win!
Whoever the principal is, they will want to access a resource. There are principal and resource based policies in fact. In the case of cross-account access , we have to use resource based policies because, the principal doesn’t exist in IAM (at the very least not within the account granting access ).
Roles, groups and policies let us administer IAM resources and permissions in a far more scalable way.
KMS has covered one way we can do encryption at rest.
SSL Termination covers most of what we need for encryption in transit. In other words, at what point are we in a safe zone?
Network security consists of:
Since the AWS Developer associate requires a lot of coverage, I’ve tried to play it smart with getting bank for buck on the way we study. I make no apologies for the amount of times I’ve said things like ‘understand the fundamentals’, or ‘think critically’ and then pointed you in the direction of tutorials and resources for you to discover things for yourself.
I hope this was helpful to you. If you have any feedback, questions, queries about this (or any) article, please feel free to contact me.
Next week is our last week! Stick around for that and we’ll cover the last parts before your exam.