To Understand IF

To Understand IF

AWS Security Token Service API Actions

AssumeRole (temp creds for upto 1hr)

Returns a set of temporary security credentials. You call this API using the credentials of an existing IAM user. This API is useful to grant AWS access to users who do not have an IAM identity (that is, to federated users). It is also useful to allow existing IAM users to access AWS resources that they don’t already have access to, such as resources in another account. For more information, see Creating Temporary Security Credentials for Delegating API Access.


Returns a set of temporary security credentials for federated users who are authenticated using a public identity provider like Login with Amazon, Facebook, or Google. This API is useful for creating mobile applications or client-based web applications that require access to AWS but where users do not have their own AWS or IAM identity. For more information, see Creating a Role to Allow AWS Access for the Mobile App.

GetFederationToken (Temp creds for upto 36hr)

Returns a set of temporary security credentials for federated users. This API differs from AssumeRole in that the default expiration period is substantially longer (up to 36 hours instead of up to 1 hour); this can help reduce the number of calls to AWS because you do not need to get new credentials as often. For more information, see Creating Temporary Security Credentials to Enable Access for Federated Users.


Returns a set of temporary security credentials to an existing IAM user. This API is useful to provide enhanced security, such as to make AWS requests when MFA is enabled for the IAM user. For more information, see Creating Temporary Security Credentials to Enable Access for IAM Users.
Information Available in Requests for Federated Users

Federated users are users who are authenticated using a system other than IAM. For example, a company might have an application for use in-house that makes calls to AWS. It might be impractical to give an IAM identity to every corporate user who uses the application. Instead, the company might use a proxy (middle-tier) application that has a single IAM identity. This proxy application first authenticates individual users using the corporate network; the proxy application then uses its IAM identity to get temporary security credentials for individual users and gives them to the user’s local copy of the corporate application. The user’s local copy of the corporate application can use these temporary credentials to call AWS.

Similarly, you might create an app for a mobile device in which the app needs to access AWS resources. In that case, you might use web identity federation, where the app authenticates the user using a well-known identity provider like Login with Amazon, Facebook, or Google. The app can then use the user’s authentication information from these providers to get temporary security credentials for accessing AWS resources.
Using Your Company’s Own Authentication System to Grant Access to AWS Resources

2.Ways to Get Temporary Security Credentials

3.Permissions in Temporary Security Credentials for Federated Users
Calls to the AssumeRole action are made using the long-term security credentials of an IAM user. The call must specify the ARN of the role to assume. The IAM user whose credentials are used to make the call must as a minimum have sts:AssumeRole permissions, and must be listed as the principal in the role that is being assumed. By default, the role being assumed determines the permissions that are granted to the temporary security credentials. The permissions of the IAM user that’s used to make the AssumeRole API have no effect on the permissions granted to the temporary security credentials that are returned by the API. Optionally, the call can include a policy that further restricts the permissions of the temporary security credentials. The resulting credentials are based on the intersection of the role’s permissions and the passed permissions. (This means that the passed permissions can never escalate the permissions defined in the role.)


How do I choose which API?

When deciding which API to use, you should consider what services are required for your use case and where you want to maintain the policies associated with your federated users.

How do you want to maintain the policies associated with your delegated users?

If you prefer to maintain permissions solely within your organization, GetFederationToken is the better choice. Since the base permissions will be derived from the IAM user making the request and you need to cover your entire delegated user base, this IAM user will require the combination of all permissions of all federated users.

If you prefer to maintain permissions within AWS, choose AssumeRole, since the base permissions for the temporary credentials will be derived from the policy on a role. Like a GetFederationToken request, you can optionally scope down permissions by attaching a policy to the request. Using this method, the IAM user credentials used by your proxy server only requires the ability to call sts:AssumeRole.


Run commands in Opsworks Instances using chef recipe

Using Custom Recipes in Opsworks

MY Recipe

Create the follwoing DIR structure:

myCookbookRepo -> myCustomCookbook -> recipe -> myCustomRecipe.rb

The name “recipe” must not be changed, remaining we can give the names we like.

vim myCustomRecipe.rb

execute 'bundle install' do
cwd '/srv/www/testapp/current'

Save it.

ZIP the directory and upload to S3 Bucket.

In Opsworks, Click “Stack” , Click “Stack Settings” , Click “Edit

Paste the AWS S3 URL for and AK , PK as well.

Now Click “Run Command” and Select “Execute Recipes” from the Command drop down list and mention the following in “Recipes to execute” box

cookbook::recipe (eg. myCustomCookbook::myCustomRecipe.rb)

Click “Execute Recipes



Execute “rake task” in Opsworks

All the Opsworks Instances have GEMS installed in 2 locations
  1. System-Wide Location (/usr/local/lib/ruby/gems/2.0.0/gems)
  2. User-Home Location, in Opsworks its Deploy user (/home/deploy/.bundler/galaxylifecms/ruby/2.0.0/gems)

The GEMS listed in Gemfile are installed in the User-Home location by Bundler

If you need to execute a custom ruby script like 

#rake my_custom_script

Chances are high that you would run into GEM dependencies errors even though you had mentioned all the required GEMS in Gemfile. 

To verify if the GEM in error have been installed by bundler or not, 

# grep gem_name Gemfile.lock

IF it exist , then the issue is the custom ruby script is pickingup up the wrong environment ie System-Wide location and not User-Home location. 

Solution :

#bundle exec rake my_custom_script

The “bundle exec” will ensure the custom rake task picks up the GEM used by the Bundler environment.

Customize Nginx config on Ruby1.9 Elastic Beanstalk

Requirement : Set a URL redirection in Nginx Configuration.

Example : =>

On Beanstalk with Phusion Passenger Standalone [3.0.17] (Ruby1.9), Nginx customization is highly discouraged. However to accomplish this, the following workaround is done :

Beanstalk generates the nginx configuration file from a ERB template each time when restarted. Hence the configuration change has to be made at the ERB template instead of Nginx configuration.

Location of the ERB Template file = /usr/share/ruby/1.9/gems/1.9.1/gems/passenger-3.0.17/lib/phusion_passenger/templates/standalone/config.erb

Following contents are appended before the last closing curly bracket:

server {
 root '<%= app[:root] %>/public/test';
 index index.html;

File Saved, phusion-passenger-nginx configuration is combined and it is Restarted

/etc/init.d/passenger restart

Create the Dir /var/app/current/public/test and a file called index.html with the below contents in it:

<meta http-equiv="refresh" content="0; url=" />

Hence the Nginx is customized.

Note : For Permanent fix we have to take Custom AMI and launch the ElasticBeanstalk environment.


Click this URL on Nginx Customization @ AWS Forum


CloudFormation Basics

CloudFormation Getting Started Guide

An AWS CloudFormation template begins with an open brace and ends with a close brace. Within those braces, you can declare six top level JSON objects: AWSTemplateFormatVersion, Description, Parameters, Mappings, Resources, and Outputs.

Naming Hierarchy
JSON Object->Eg.Resource->Attributes->Eg.Type & Properties->Eg. AWS::EC2::Instance->Resource Property Type->Eg. EC2 Tag

This is mostly required compared to all others. The Resources object contains the definitions of the AWS resources you want to create with the template.
The resource declaration begins with a string that specifies the logical name for the resource. As you’ll see, the logical name can be used to refer to resources within the template.

Each Resource has attributes – Type & Properties

A resource must have a Type attribute, which defines the kind of AWS resource you want to create. The Type attribute has a special format:
For example, the resource type for an Amazon S3 bucket is AWS::S3::Bucket.

    "Resources" : {
        "HelloBucket" : {
            "Type" : "AWS::S3::Bucket"



You use the Parameters object to declare values that can be passed to the template when you create the stack. A parameter is an effective way to specify sensitive information, such as user names and passwords, that you don’t want to store in the template itself. It is also a way to specify information that may be unique to the specific application or configuration you are deploying, for example, a domain name or instance type. When you create the WordPress stack later in this section, you’ll see the set of parameters declared in the template appear on the Specify Parameters page of the Create Stack wizard, where you can specify the parameters just before creating the stack.

The parameters are used in the template to specify values used in properties in the Amazon RDS DB Instance resource

Receiving User Input Using Input Parameters

You use mappings to declare conditional values that are evaluated in a similar manner as a switch statement. Usually The template uses mappings to select the correct Amazon machine image (AMI) for the region and the architecture type for the instance type.

Outputs define custom values that are returned by the aws cloudformation describe-stacks command and in the AWS Management Console’s Outputs tab after the stack is created. You can use output values to return information from the resources in the stack, such as the URL for a website created in the template.

Make sure you have a valid EC2 key pair, and make note of the Key Pair Name, before you create the stack.

CF Functions
AWS CloudFormation has a number of intrinsic functions that you can use to refer to other resources and their properties. You can use the Ref function to refer to an identifying property of a resource. Frequently, this is the physical name of the resource; however, sometimes it can be an identifier, such as the IP address for an AWS::EC2::EIP

Explaining the Ref Function :

The Ref function is handy if the parameter or the value returned for a resource is exactly what you want; however, you may need other attributes of a resource. For example, if you want to create a CloudFront distribution with an S3 origin, you need to specify the bucket location by using a DNS-style address. A number of resources have additional attributes whose values you can use in your template. To get these attributes, you use the Fn::GetAtt function.

Explaining the Fn:GetAtt :

New Features in CF –!

ARN – AWS Documentation Excerpts

Here are some example ARNs:

<!– AWS Elastic Beanstalk application version –>

arn:aws:elasticbeanstalk:us-east-1:123456789012:environment/My App/MyEnvironment

<!– IAM user name –>


<!– Amazon RDS tag –>


<!– Amazon S3 bucket (and all objects in it)–>


The following are the general formats for ARNs; the specific components and values used depend on the AWS service.


ARN Examples for EC2
Amazon Elastic Compute Cloud (Amazon EC2)




ARN Examples of RDS
ARNs are used in Amazon RDS only with tags for DB instances. For more information, see Tagging a DB Instance in the Amazon Relational Database Service User Guide.




ARN Examples of Route53

Amazon Route 53


Note that Amazon Route 53 does not require an account number or region in ARNs.


ARN Examples of Amazon S3


Note that Amazon S3 does not require an account number or region in ARNs.


AWS Service Namespaces

When you create AWS IAM policies or work with Amazon Resource Names (ARNs), you identify an AWS service using a namespace. For example, the namespace for Amazon S3 is s3, and the namespace for Amazon EC2 is ec2. You use namespaces when identifying actions and resources.

The following example shows an IAM policy where the value of the Action elements and the values in the Resource and Condition elements use namespaces to identify the services for the actions and resources.


The following lists the AWS service namespaces.



Service Namespace
Auto Scaling autoscaling
AWS Account Billing aws-portal
AWS CloudFormation cloudformation
Amazon CloudFront cloudfront
CloudWatch cloudwatch
Amazon DynamoDB dynamodb
Amazon EC2 ec2
AWS Elastic Beanstalk elasticbeanstalk
Elastic Load Balancing elasticloadbalancing
Amazon Elastic MapReduce elasticmapreduce
Amazon ElastiCache elasticache
Amazon Glacier glacier
IAM iam
AWS Marketplace aws-marketplace
AWS OpsWorks opsworks
Amazon RDS rds
Amazon Route 53 route53
Amazon S3 s3
Amazon SES ses
Amazon SimpleDB sdb
Amazon SNS sns
Amazon SQS sqs
Amazon SWF swf
AWS Storage Gateway storagegateway
AWS Support support
Amazon VPC ec2

IAM Users Best Practices – Excerpts from AWS Documentation!

Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.
Permissions can be assigned in two ways: as user-based permissions or as resource-based permissions. User-based permissions are attached to an IAM user, group, or role and let you specify what that user, group, or role can do. For example, you can assign permissions to the IAM user named Bob, stating that he has permission to use the Amazon Elastic Compute Cloud (Amazon EC2) RunInstances action and that he has permission to get items from an Amazon DynamoDB table named MyCompany. The user Bob might also be granted access to manage his own IAM security credentials.
Resource-based permissions are attached to a resource like an Amazon S3 bucket or an Amazon SNS topic. They let you specify who has access to the resource and what actions they can perform on it.
When you add a new user we need to check if the policies that we intend to give the user are already existing as part of the Group or not. If so then take the Group that mostly match with the User and remaining policies of the group will be made as Deny for that particular user.

IAM Policies:

To assign permissions to a user, group, role, or resource, you create a policy, which is a document that explicitly lists permissions. In its most basic sense, a policy lets you specify the following:

Actions: what actions you will allow. Each AWS service has its own set of actions. For example, you might allow a user to use the Amazon S3 ListBucket action, which returns information about the items in a bucket. Any actions that you don’t explicitly allow are denied.

Resources: which resources you allow the action on. For example, what specific Amazon S3 buckets will you allow the user to perform the ListBucket action on? Users cannot access any resources that you have not explicitly granted permissions to.

Effect: what the effect will be when the user requests access—either allow or deny. Because the default is that resources are denied to users, you typically specify that you will allow users access to resource.

Policies are documents that are created using JSON. A policy consists of one or more statements, each of which describes one set of permissions. Here’s an example of a simple policy.

To specify resource-based permissions, you can attach a policy to the resource, such as an Amazon SNS topic or Amazon S3 bucket. In that case, the policy has to include information about who is allowed to access the resource, known as the principal. (For user-based policies, the principal is the IAM user that the policy is attached to, or the user who gets the policy from a group.)

The following example shows a policy that might be attached to an Amazon S3 bucket and that lets IAM user Bob in account 123456789012 perform any actions in mybucket.

“Id”: “S3-Account-Permissions”,
“Statement”: [
“Sid”: “1”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“Action”: “s3:*”,
“Resource”: “arn:aws:s3:::mybucket/*”

IAM Policy Evaluation Logic

1. The decision starts by assuming that the request will be denied.

2. The enforcement code evaluates all user-based and resource-based policies that are applicable to the request (based on the resource, principal, action, and conditions).

The order in which the enforcement code evaluates the policies is not important.

3. In all those policies, the enforcement code looks for an explicit deny instruction that would apply to the request.

If the code finds even one explicit deny that applies, the code returns a decision of “deny” and the process is finished.

4. If no explicit deny is found, the code looks for any “allow” instructions that would apply to the request.

If it finds even one explicit allow, the code returns a decision of “allow” and the service continues to process the request.

5. If no allow is found, the final decision is “deny.”
The distinction between a request being denied by default and an explicit deny in a policy is important. By default, a request is denied, but this can be overridden by an allow. In contrast, if a policy explicitly denies a request, that deny can’t be overridden.

Use roles for applications that run on Amazon EC2 instances

Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions, but that isn’t a user or group. Roles also don’t have their own permanent set of credentials the way IAM users do. Instead, a role is assumed by other entities. Credentials are then either associated with the assuming identity, or IAM dynamically provides temporary credentials (in the case of Amazon EC2).

When you launch an Amazon EC2 instance, you can specify a role for the instance as a launch parameter. Applications that run on the EC2 instance can use the role’s credentials when they access AWS resources. The role’s permissions determine what the application is allowed to do.
Delegate by using roles instead of by sharing credentials
You might need to allow users from another AWS account to access resources in your AWS account. If so, don’t share security credentials, such as access keys, between accounts. Instead, use IAM roles. You can define a role that specifies what permissions the IAM users in the other account are allowed, and from which AWS accounts IAM users are allowed to assume the role.
Rotate credentials regularly
Change your own passwords and access keys regularly, and make sure that all IAM users in your account do as well. That way, if a password is compromised without your knowledge, you limit how long the password can be used to access your resources.
To make it easier to rotate credentials, let your users manage their own passwords.
Use policy conditions for extra security
To the extent that it’s practical, define the conditions under which the policy allows access to a resource. For example, you can write conditions to specify a range of allowable IP addresses for a request, or you can specify that a request is allowed only within a specified date range or time range. You can also set conditions that require the use of SSL or MFA. For example, you can require that a user has authenticated with an MFA device in order to be allowed to terminate an Amazon EC2 instance. The more explicitly you can define when resources are available (and otherwise unavailable), the safer your resources will be.
As an example, let’s say you want to let user John access your Amazon SQS queue under the following conditions:

The time is after 12:00 noon on 8/16/2013

The time is before 3:00 p.m. on 8/16/2013

The request (IAM or SQS) or message (SNS) comes from an IP address within the range to or to

Your condition block has three separate conditions, and all three of them must be met for John to have access to your queue, topic, or resource.

The following shows what the condition block looks like in your policy. The two values for aws:SourceIp are evaluated using OR. The three separate conditions are evaluated using AND.

“Condition” : {
“DateGreaterThan” : {
“aws:CurrentTime” : “2013-08-16T12:00:00Z”
“DateLessThan”: {
“aws:CurrentTime” : “2013-08-16T15:00:00Z”
“IpAddress” : {
“aws:SourceIp” : [“”, “”]
Available Keys for Conditions

Keys in a condition represent values that are part of the request sent by a user. AWS provides the following predefined keys for all AWS services that support the IAM for access control:

aws:CurrentTime—To check for date/time conditions.

aws:EpochTime—To check for date/time conditions using a date in epoch or UNIX time.

aws:MultiFactorAuthAge—To check how long ago (in seconds) the MFA-validated security credentials making the request were issued using Multi-Factor Authentication (MFA). Unlike other keys, if MFA is not used, this key is not present (see Existence of Condition Keys, Numeric Conditions and Using Multi-Factor Authentication (MFA) Devices with AWS.

aws:principaltype—To check the type of principal (user, account, federated user, etc.) for the current request.

aws:SecureTransport—To check whether the request was sent using SSL.

aws:SourceArn—To check the source of the request, using the Amazon Resource Name (ARN) of the source. (This value is available for only some services. For more information, see Amazon Resource Name (ARN) under “Element Descriptions” in the Amazon Simple Queue Service Developer Guide.)

aws:SourceIp—To check the requester’s IP address.

aws:UserAgent—To check the requester’s client application.

aws:userid—To check the requester’s user ID.

aws:username—To check the requester’s user name.

Key names are case sensitive.
Some AWS services also provide service-specific keys. For example, for information about keys that you can use in policies for Amazon S3 resources, see Amazon S3 Policy Keys in the Amazon Simple Storage Service Developer Guide. For keys that are available in other services, see the documentation for the individual services.

Permissions Required for Using Roles with Amazon EC2

To launch an instance with a role, the developer must have permission to launch Amazon EC2 instances and permission to pass IAM roles.

The following sample policy allows users to use the AWS Management Console to launch an instance with a role. The policy allows a user to pass any role and to perform all Amazon EC2 actions by specifying an asterisk (*). The ListInstanceProfiles action allows users to view all the roles that are available on the AWS account.

Example Policy that grants a user permission to launch an instance with any role by using the Amazon EC2 console

“Version”: “2012-10-17”,
“Statement”: [{
Restricting Which Roles Can Be Passed to Amazon EC2 Instances (Using PassRole)

You can use the PassRole permission to prevent users from passing a role to Amazon EC2 that has more permissions than the user has already been granted, and then running applications under the elevated privileges for that role. In the role policy, allow the PassRole action and specify a resource (such as arn:aws:iam::111122223333:role/ec2Roles/*) to indicate that only a specific role or set of roles can be passed to an Amazon EC2 instance.

The following sample policy allows developers to use the Amazon EC2 API to launch an instance with a role. The Resource element specifies an Amazon Resource Name (ARN). By specifying the ARN, the policy grants the user to pass only the Get-pics role.

Example Policy that grants a user permission to launch an instance with a role by using the Amazon EC2 API

“Version”: “2012-10-17”,
“Statement”: [{