We start with discussing the “Shared Responsibility” which simply defines security at AWS. It’s split to two parts. First part is all taken care of by AWS themselves or AWS responsibility “Security of the Cloud”. They’re concerned by the physical security of the premises and facilities or simply the infrastructure and hardware in which all of the services you’re using operates. Second part is called Customer responsibility “Security in the Cloud”. That goes from doing the configuration work of all the services you choose to work with, to protecting your users data, to regularly applying security patches and also making use of the security services provided by AWS to secure your applications that, for example, are deployed on an EC2 instance. AWS has tools like AWS Identity and Access Management (IAM), Amazon Cognito.
AWS Identity and Access Management (IAM)
Let’s say you’re a tech lead at your company and you just created an AWS account. That’s when you take advantage of IAM! As the root user, you create an account for each engineer on the team and you only provision access to specific services that you know they’ll be using as a best practice. You have other controls like how the account could be accessed (via AWS Console access or Programmatic access) and then you attach policies needed for this type of account. Not only you could give restricted access to your users but also admin access could be provisioned by you through adding a JSON document that describes it.
As an additional layer of security to accounts that have admin privileges, it’s considered a best practice to add MFA (stands for Multi-factor Authentication). It adds another verification check when you login and should be enabled for the root account and every other account with admin access. It can also be used to control to the service APIs. It’ll be a short code coming from an application like Google authenticator or a YubiKey.
Managing multiple accounts using AWS Organizations
One way to manage your account is to create IAM groups. We start by creating an IAM group for admin users, assign engineers to it that will need admin access to resources and from there we create more groups with each having suitable policies attached to it and assign users to them.
But what happens when you start growing as an organization and multiple accounts have to be created? Surely, there’re ways and best practices in managing multiple accounts on AWS. You want to make sure your admins could monitor the overall activity across the accounts and that each IAM group has only the permissions they need and nothing more. You want all the accounts’ bills to be rolled up to one central account so that you pay for all the used services combined. Using AWS Organizations, you can have split groups of accounts, monitor and govern access to AWS services by policies, automate account creation, have a single payment method for all accounts and share resources across all accounts. How it works?
You create a master AWS account then create an organization in the master account. It’s recommended that you keep this account free of any operational AWS resources.
Then, you could create Organizational Units, which is simply a way to group some accounts together. Or you could create member accounts right away.
Create service control policies to be attached to OUs and restrict actions by member accounts. A good practice is to apply SCPs to OUs instead of individual accounts and make sure that every account belongs to an OU.
Use AWS CloudTrail in the master account to centrally track all AWS usage in the member accounts.
Additional best practices:
- A great example was that you could define your application resources once on your Amazon VPC subnet and share them across your organization using the AWS Resource Access Manager service (AWS RAM for short).
Authentication and Authorization
There are several use cases but I’ll mention a couple. First one is if you have an internal reporting tool hosted on AWS and only employees can login and see the reports. But your company’s employees identities are on an Active Directory. You can simply federate (put them together?) this Active Directory with Amazon Cognito. Another use case is to have resources talking to other resources and that’s where you need to validate the permissions of your app’s resources. Let’s say you have a containerized app running on EKS and needs to make an API call to query a table in an AWS DynamoDB. You’ll need to use IAM Roles. These are short-term credentials that you’ll need to securely validate these API calls and manage permissions for actions that your app is allowed to perform on DynamoDB tables. IAM Roles enable you to grant resources access to data without distributing passwords or API keys and by using them you’re applying the “granting least privilege access” concept.
Creating Policies in AWS
We create IAM policies to users, groups or roles in order to assign permissions using the visual editor which is easier and doesn’t requiring to write JSON. You could always test your custom policy using the IAM policies simulator. IAM Policies types include:
AWS Managed Policy which is created and administered by AWS and it’s designed for most common use cases.
Customer Managed Policy which you could create and administer in your account. You could try to copy an existing Managed Policy and tailor it to your environment.
Inline Policy is a policy that’s embedded in an IAM identity. You can create a policy and embed it in a identity, either when you create the identity or later.
One of the advantages to use managed policies over inline policies is Central change management. When you change a managed policy, the change is applied to all principal entities that the policy is attached to. For example, if you want to add permission for a new AWS API, you can update the managed policy to add the permission. (If you’re using an AWS managed policy, AWS updates to the policy.) When the policy is updated, the changes are applied to all principal entities that the policy is attached to. In contrast, to change an inline policy you must individually edit each identity that contains the policy. For example, if a group and a role both contain the same inline policy, you must individually edit both principal entities in order to change that policy.
Amazon Single Sign-On
A service that lets you manage SSO access and user permissions across multiple AWS accounts in an AWS Organization.
Difference between Cognito User Pools and Identity Pools
- User Pools are for user registration and authentication. A Cognito User Pool handles all of this and as a developer you just need to use the SDK to retrieve user related information.
- An Identity Pool is a way to authorize your users to use the various AWS services. Like having access to an S3 bucket to upload a file. Identities could be coming from a Cognito User Pool or Facebook or Google.
Resources: