AWS CloudFormation
User Guide (API Version 2010-05-15)
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.Did this page help you?  Yes | No |  Tell us about it...

Controlling Access with AWS Identity and Access Management

With AWS Identity and Access Management (IAM), you can create IAM users to control who has access to which resources in your AWS account. You can use IAM with AWS CloudFormation to control what AWS CloudFormation actions users can perform, such as view stack templates, create stacks, or delete stacks. In addition, you can manage what AWS services and resources are available to each user. That way, you can control which resources users can create or update when they create, update, or delete stacks. For example, you can specify which users can launch Amazon EC2 instances, terminate database instances, or update VPCs.

For more information about all the services that you can control access to, see AWS Services that Support IAM in Using IAM.

AWS CloudFormation Actions and Resources

When you create a group or an IAM user in your AWS account, you can associate an IAM policy with that group or user. The policy specifies what permissions the IAM user has to which stacks. For example, imagine you have a group of entry-level developers. You can create a Junior application developers group and include each entry-level developer's IAM user in that group. Then, you associate a policy with that group that allows users only to view AWS CloudFormation stacks. In this scenario, you might have a policy such as the following sample:

A sample policy that grants view stack permissions

{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect":"Allow",
        "Action":[
            "cloudformation:DescribeStacks",
            "cloudformation:DescribeStackEvents",
            "cloudformation:DescribeStackResources"
        ],
        "Resource":"*"
    }]
}

The policy grants permissions to all the listed actions in the Action element. In the Resource element, we specify an asterisk (*), a wild card that allows the actions to be performed on all AWS CloudFormation stacks.

In addition to AWS CloudFormation actions, IAM users who create or delete stacks require permissions to other actions that are related to resources in a given AWS CloudFormation template. For example, if you have a template that describes an Amazon SQS Queue, the user must have the corresponding IAM permissions for Amazon SQS actions in order to successfully create the stack, as shown in the following sample policy:

A sample policy that grants create and view stack actions and all Amazon SQS actions

{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect":"Allow",
        "Action":[
            "sqs:*",
            "cloudformation:CreateStack",
            "cloudformation:DescribeStacks",
            "cloudformation:DescribeStackEvents",
            "cloudformation:DescribeStackResources",
            "cloudformation:GetTemplate",
            "cloudformation:ValidateTemplate"  
        ],
        "Resource":"*"
    }]
}

AWS CloudFormation also supports resource-level permissions, so you can specify actions for a specific stack, as shown in the following policy:

A sample policy that denies the delete and update stack actions for the MyProductionStack

{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect":"Deny",
        "Action":[
            "cloudformation:DeleteStack",
            "cloudformation:UpdateStack"
        ],
        "Resource":"arn:aws:cloudformation:us-east-1:123456789012:stack/MyProductionStack/*"
    }]
}

The sample policy uses a wild card at the end of the stack name so that delete stack and update stack are denied on the full stack ID (such as arn:aws:cloudformation:us-east-1:123456789012:stack/MyProductionStack/abc9dbf0-43c2-11e3-a6e8-50fa526be49c) and on the stack name (such as MyProductionStack).

For a list of all AWS CloudFormation actions that you can allow or deny, see the AWS CloudFormation API Reference.

AWS CloudFormation Conditions

In an IAM policy, you can optionally specify conditions that control when a policy is in effect. AWS CloudFormation does not have service-specific conditions. However, you can use the AWS-wide conditions, such as DateLessThan, which specifies when a policy stops taking effect. For more information about AWS-wide conditions, see Condition in IAM Policy Elements Reference in Using IAM.

Note

Do not use the aws:SourceIp condition. AWS CloudFormation provisions resources by using its own IP address, not the IP address of the originating request. For example, when you create a stack, AWS CloudFormation makes requests from its IP address to launch an Amazon EC2 instance or to create an Amazon S3 bucket, not the IP address from the CreateStack call or the aws cloudformation create-stack command.

IAM Resources in AWS CloudFormation Templates

Before you can create a stack, AWS CloudFormation validates your template. During the validation, AWS CloudFormation also checks your template for AWS resources that you should be aware of. Currently, AWS CloudFormation checks only for IAM resources in your templates. We recommend that you review the permissions associated with each IAM resource. IAM resources, such as an IAM user with full access, can access and modify any resource in your AWS account. To ensure that you've reviewed all IAM resources, you must acknowledge that the template is creating those resources before AWS CloudFormation creates the stack.

You can acknowledge the capabilities of AWS CloudFormation templates by using the AWS CloudFormation console, command line, or API:

  • In the AWS CloudFormation console, select I acknowledge that this template may create IAM resources on the Specify Parameters page of the Create Stack or Update Stack wizards.

  • For the AWS Command Line Interface, specify the CAPABILITY_IAM value for the --capabilities parameter when you use the aws cloudformation create-stack and aws cloudformation update-stack commands.

  • For the API, specify the Capabilities.member.1=CAPABILITY_IAM parameter when you use the CreateStack and UpdateStack actions.

Manage Credentials for Applications Running on Amazon EC2 Instances

If you have an application that runs on an Amazon EC2 instance and needs to make requests to AWS resources such as Amazon S3 buckets or an DynamoDB table, the application requires AWS security credentials. However, distributing and embedding long-term security credentials in every instance that you launch is a challenge and a potential security risk. Instead of using long-term credentials, like IAM user credentials, we recommend that you create an IAM role that is used when an Amazon EC2 instance is launched. An application can then get temporary security credentials from the Amazon EC2 instance. You don't have to embed long-term credentials on the instance. Also, to make managing credentials easier, you can specify just a single role for multiple Amazon EC2 instances; you don't have to create unique credentials for each instance.

For a template snippet that shows how to launch an instance with a role, see IAM Role Template Examples.

Note

Applications on instances that use temporary security credentials can call any AWS CloudFormation actions. However, because AWS CloudFormation interacts with many other AWS services, you must verify that all the services that you want to use support temporary security credentials. For more information, see AWS Services that Support AWS STS.

Grant Temporary Access with IAM Roles

In some cases, you might want to grant users with no AWS credentials temporary access to your AWS account. Instead of creating and deleting long-term credentials whenever you want to grant temporary access, use IAM roles. From one IAM role, you can programmatically create and then distribute many temporary security credentials (which include an access key, secret access key, and security token). These credentials have a limited life, so they cannot be used to access your AWS account after they expire. You can also create multiple IAM roles in order to grant individual users different levels of permissions. IAM roles are useful for scenarios like federated identities and single sign-on.

A federated identity is a distinct identity that you can use across multiple systems. For enterprise users with an established on-premises identity system (such as LDAP or Active Directory), you can handle all authentication with your on-premises identity system. After a user has been authenticated, you provide temporary security credentials from the appropriate IAM role. For example, you can create an administrators role and a developers role, where administrators have full access to the AWS account and developers have permissions to work only with AWS CloudFormation stacks. After an administrator is authenticated, the administrator is authorized to obtain temporary security credentials from the administrators role. However, for developers, they can obtain temporary security credentials from only the developers role.

You can also grant federated users access to the AWS Management Console. After users authenticate with your on-premises identity system, you can programmatically construct a temporary URL that gives direct access to the AWS Management Console. When users use the temporary URL, they won't need to sign in to AWS because they have already been authenticated (single sign-on). Also, because the URL is constructed from the users' temporary security credentials, the permissions that are available with those credentials determine what permissions users have in the AWS Management Console.

Note

AWS CloudFormation interacts with many other AWS services. When you use temporary security credentials with AWS CloudFormation, verify that all the services that you want to use support temporary security credentials. For more information, see AWS Services that Support AWS STS.

For more information, see the following related resources in Using Temporary Security Credentials: