Chapter 4

Part 2. Building event-driven applications

Chapter 4. Managing security

This chapter covers

• Introducing AWS Identity and Access Management
• Writing policies to allow or deny access to AWS resources
• Using policy variables to make policies more flexible
• Assuming roles to avoid the use of hard-coded AWS credentials
• Using roles with AWS Lambda functio

using the AWS Lambda interface from the command line

exposed those functions via a web API

AWS, mostly based on AWS Identity and Access Management (IAM).

how to protect your functions and applications implemented using AWS Lambda and (optionally)
the Amazon API Gateway

the resources used by your application, must be protected to avoid unauthorized access

let developers focus on the functionalities they want to build and simplify the realization of an overall
secure application.

AWS IAM

manage identities within an AWS account

4.1. Users, groups, and roles

interact with AWS APIs.

directly, via the AWS CLI

via SDKs

via the web console

AWS needs to understand who the user making the API call is (this is the authentication)

AWS credentials are used to sign API calls.

Credentials can be temporary

new AWS account, it only has its own root account credentials that give unrestricted access to all
resources within the account

use those root credentials only for the first login and then create users (and roles, as you’ll see next in
this chapter) with limited permissions for daily use, keeping the root credentials in a safe place for
when you need them.

AWS Identity and Access Management, you can create groups and users to reproduce the organization
of your company

Identity & Access Management (IAM) from the Security & Identity section.

you can create roles.

difference between roles and groups is how they’re used:

• Users can be added to groups, inheriting the permissions given to those groups.
• Users, applications, or AWS services can assume a role, inheriting the permissions given to the
• role.

AWS Lambda can use roles: functions can assume a role to get the necessary permissions to do their
job.

a role to get read (or write) permission to a storage service, such as Amazon S3,[1]

To make users, groups, and roles useful, you need to attach them to one or more policies (figure 4.5).
Policies give the actual permissions, describing what those users, groups, or roles are (or are not)
allowed to do within the account.

r authentication, you need security credential

Roles don’t have credentials assigned to them, but when a user, an application, or an AWS service
assumes a role, it gets temporary credentials that will authorize it to do what’s described in the
policies attached to the role

User (and root account) security credentials are composed of

• An access key ID
• A secret access key

access key ID is added to all AWS API calls

he secret access key is never sent on the wire, but is used to sign the API calls.

AWS services (such as Amazon Cognito) and the CLI and SDKs are designed to manage that on
your behalf. Temporary credentials are slightly different from standard security credentials and are
composed of

• An access key ID
• A secret access key
• A security (or session) token

4.2. Understanding policies

policies have effects, which tell if you’re allowing or denying access to perform actions on specific
resources

AWS API calls and are expressed by specifying the AWS service and the API call(s) you want to
give (or remove) access to. You could use an asterisk (*) to give a service access to all actions

There are three types of policies, each covering a different kind of authorization for AWS resources
(figure 4.8):
User-based policies can be attached to users, groups, or roles and describe what a user (or an application or an AWS service) can do. Resource-based policies can be attached directly to AWS resources and describe who can do what on those resources. For example, S3 bucket policies authorize access to S3 buckets. Trust policies describe who can assume a role. Roles used by AWS Lambda have specific trust policies that allow functions to assume those roles.

Policies are written using a JSON syntax. In figure 4.9 you see the different elements that compose
a policy.

Statements include the effect (allow or deny), the actions, and the resources, and can optionally
include one or more conditions that further limit the scope of the policy.

you can limit access to Amazon S3 based on the HTTP referrer used in the API calls

Policies can be directly attached to users, groups or roles

the same policy is used with multiple roles, one that can be assumed by a Lambda function and
one by users authenticated via Amazon Cognito

create a managed policy using the Policy link in the left of the AWS IAM console

4.3. Policies in practice

policies that authorize access to Amazon S3 resources.

you need to give permissions to get the list of all the buckets in your account

To limit read/write access only to a specific prefix inside a bucket, you can

• Add a condition to actions that work on a bucket (such as “ListBucket”)
• Include the prefix in the resource for actions that work on objects
• (such as “PutObject,” “GetObject,” “DeleteObject”)
• 
• read/write access to items in a specific DynamoDB table.

Resources are specified in statements using Amazon Resource Names (ARNs) that are unique
. S3 bucket names are unique globally, so you can specify only the bucket name to identify the
resource. DynamoDB table

the region code to build the ARN of the DynamoDB table by looking up the
value at http://docs.aws.amazon.com/general/latest/gr/rande.html#ddb_region.

4.4. Using policy variables

you may want to use values in a policy

dynamic parameters, such as who’s making the request,

able 4.1. Common policy variables that you can use to enhance your policies (view table figure)

Policy variable	Description and sample usage
aws:SourceIp	The IP address of who’s making the request to the AWS API; it can be used in an “IpAddress” condition to limit the validity of a policy to a specific IP range: "Condition": { "IpAddress" : { "aws:SourceIp" : ["10.1.2.0/24","10.2.3.0/24"] } } To exclude an IP range from the validity of a policy, you can use the “NotIpAddress” condition: "Condition": { "NotIpAddress": { "aws:SourceIp": "192.168.0.0/16" } }
	Be careful that the previous policies work only if the requests are directly made by a user, but wouldn’t work if the requests come through another AWS service, such as AWS CloudFormation.
aws:CurrentTime	The current time of the request; it can be used to give or block access before or after a specific date and time. A condition valid only during the month of January 2016 would be "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2016-01-01T00:00:00Z"}, "DateLessThan": {"aws:CurrentTime": "2016-02-01T00:00:00Z"} }
aws:SecureTransport	A Boolean value that tells if the API request is using a secure transport such as HTTPS. This is particularly useful to force S3 access via “https://...” URLs. For example, if you host the static assets of a website on S3, you can use an S3 bucket policy (a particular case of resource-based policies) to give public access to reads only in HTTPS using the following statement (that can be included in a wider policy): "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::your-bucket/*", "Condition": { "Bool": { "aws:SecureTransport": "true" } } } ]
aws:MultiFactor-AuthPresent	A Boolean value that tells if the request was made using Multi-Factor Authentication (MFA) using a hardware or virtual MFA device. A sample condition (that you can include in a statement as part of a policy) would be "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
aws:Referer	The HTTP referrer (as described by the relevant HTTP header) in the request. Using this policy variable in a condition, S3 bucket policies (a particular case of resource-based policies) can limit access only to requests that originate from specific webpages. For example, if you put the static assets of a website (such as images, CSS, or JavaScript files) on S3, you can give access to everyone to read the objects and use this policy variable to avoid other websites linking to your assets. A sample statement that you can include in a policy would be "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::your-bucket/*", "Condition": { "StringLike": {"aws:Referer": [ "http://www.your-website.com/*", http://your-website.com/* ] } } } ]

4.5. Assuming roles

Roles can be assumed by users, applications, or AWS services to get specific permissions on AWS
resources without hard-coding AWS credentials in your application

AWS Lambda (which we’re exploring in this book) can assume an IAM role.

Using roles, you don’t need to put AWS credentials explicitly in your code or in a file distributed
with your application,

Roles have two policies attached to them:

• A user-based policy describing the permissions that the role gives.
• A trust policy describing who can assume the role; for example, a user in the same AWS account
• or in a different account, or an AWS service. This is sometimes called the trust relationship of
• the role.

when you created your first AWS Lambda function “greetingsOnDemand,” you created a
“Lambda basic execution” role and assigned that role to the function.

ow the role is used by AWS Lambda to have a better understanding of all the moving parts.
The greetingsOnDemand function is executed by AWS Lambda, a service that has a trust relationship
with the “Lambda basic execution” role and can assume that role for the execution of the function.