Identity and Access Management for AWS Cloud9

AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be authenticated (signed in) and authorized (have permissions) to use AWS Cloud9 resources. IAM is an AWS service that you can use with no additional charge.

Audience

How you use AWS Identity and Access Management (IAM) differs, depending on the work that you do in AWS Cloud9.

Service user – If you use the AWS Cloud9 service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more AWS Cloud9 features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in AWS Cloud9, see Troubleshooting AWS Cloud9 identity and access.

Service administrator – If you're in charge of AWS Cloud9 resources at your company, you probably have full access to AWS Cloud9. It's your job to determine which AWS Cloud9 features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with AWS Cloud9, see How AWS Cloud9 works with IAM.

IAM administrator – If you're an IAM administrator, you might want to learn details about how you can write policies to manage access to AWS Cloud9. To view example AWS Cloud9 identity-based policies that you can use in IAM, see Identity-based policy examples for AWS Cloud9.

Authenticating with identities

Authentication is how you sign in to AWS using your identity credentials. You must be authenticated (signed in to AWS) as the AWS account root user, as an IAM user, or by assuming an IAM role.

You can sign in to AWS as a federated identity by using credentials provided through an identity source. AWS IAM Identity Center (IAM Identity Center) users, your company's single sign-on authentication, and your Google or Facebook credentials are examples of federated identities. When you sign in as a federated identity, your administrator previously set up identity federation using IAM roles. When you access AWS by using federation, you are indirectly assuming a role.

Depending on the type of user you are, you can sign in to the AWS Management Console or the AWS access portal. For more information about signing in to AWS, see How to sign in to your AWS account in the AWS Sign-In User Guide.

If you access AWS programmatically, AWS provides a software development kit (SDK) and a command line interface (CLI) to cryptographically sign your requests by using your credentials. If you don't use AWS tools, you must sign requests yourself. For more information about using the recommended method to sign requests yourself, see Signing AWS API requests in the IAM User Guide.

Regardless of the authentication method that you use, you might be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see Multi-factor authentication in the AWS IAM Identity Center User Guide and Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

AWS account root user

When you create an AWS account, you begin with one sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you don't use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform the tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see Tasks that require root user credentials in the IAM User Guide.

Federated identity

As a best practice, require human users, including users that require administrator access, to use federation with an identity provider to access AWS services by using temporary credentials.

A federated identity is a user from your enterprise user directory, a web identity provider, the AWS Directory Service, the Identity Center directory, or any user that accesses AWS services by using credentials provided through an identity source. When federated identities access AWS accounts, they assume roles, and the roles provide temporary credentials.

For centralized access management, we recommend that you use AWS IAM Identity Center. You can create users and groups in IAM Identity Center, or you can connect and synchronize to a set of users and groups in your own identity source for use across all your AWS accounts and applications. For information about IAM Identity Center, see What is IAM Identity Center? in the AWS IAM Identity Center User Guide.

IAM users and groups

An IAM user is an identity within your AWS account that has specific permissions for a single person or application. Where possible, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see Rotate access keys regularly for use cases that require long-term credentials in the IAM User Guide.

An IAM group is an identity that specifies a collection of IAM users. You can't sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named IAMAdmins and give that group permissions to administer IAM resources.

Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see When to create an IAM user (instead of a role) in the IAM User Guide.

IAM roles

An IAM role is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by switching roles. You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see Using IAM roles in the IAM User Guide.

IAM roles with temporary credentials are useful in the following situations:

To learn whether to use IAM roles or IAM users, see When to create an IAM role (instead of a user) in the IAM User Guide.

Managing access using policies

You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see Overview of JSON policies in the IAM User Guide.

Administrators can use AWS JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

By default, users and roles have no permissions. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. The administrator can then add the IAM policies to roles, and users can assume the roles.

IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the iam:GetRole action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API.

Identity-based policies

Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see Creating IAM policies in the IAM User Guide.

Identity-based policies can be further categorized as inline policies or managed policies. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see Choosing between managed policies and inline policies in the IAM User Guide.

Resource-based policies

Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must specify a principal in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.

Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.

Access control lists (ACLs)

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see Access control list (ACL) overview in the Amazon Simple Storage Service Developer Guide.

Other policy types

AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types.

Multiple policy types

When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see Policy evaluation logic in the IAM User Guide.

How AWS Cloud9 works with IAM

Before you use IAM to manage access to AWS Cloud9, learn what IAM features are available to use with AWS Cloud9.

To get a high-level view of how AWS Cloud9 and other AWS services work with most IAM features, see AWS services that work with IAM in the IAM User Guide.

Identity-based policies for AWS Cloud9

Supports identity-based policies: Yes

Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see Creating IAM policies in the IAM User Guide.

With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. You can't specify the principal in an identity-based policy because it applies to the user or role to which it is attached. To learn about all of the elements that you can use in a JSON policy, see IAM JSON policy elements reference in the IAM User Guide.

Identity-based policy examples for AWS Cloud9

To view examples of AWS Cloud9 identity-based policies, see Identity-based policy examples for AWS Cloud9.

Resource-based policies within AWS Cloud9

Supports resource-based policies: No

Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must specify a principal in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.

To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. Adding a cross-account principal to a resource-based policy is only half of establishing the trust relationship. When the principal and the resource are in different AWS accounts, an IAM administrator in the trusted account must also grant the principal entity (user or role) permission to access the resource. They grant permission by attaching an identity-based policy to the entity. However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required. For more information, see Cross account resource access in IAM in the IAM User Guide.

AWS Cloud9 doesn't support resource-based policies but you can still control AWS Cloud9 environment resource permissions for AWS Cloud9 environment members via the AWS Cloud9 API and AWS Cloud9 IDE.

Policy actions for AWS Cloud9

Supports policy actions: Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Action element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Policy actions usually have the same name as the associated AWS API operation. There are some exceptions, such as permission-only actions that don't have a matching API operation. There are also some operations that require multiple actions in a policy. These additional actions are called dependent actions.

Include actions in a policy to grant permissions to perform the associated operation.

To see a list of AWS Cloud9 actions, see Actions defined by AWS Cloud9 in the Service Authorization Reference.

Policy actions in AWS Cloud9 use the following prefix before the action:

account

To specify multiple actions in a single statement, separate them with commas.

"Action": [
      "account:action1",
      "account:action2"
         ]

To view examples of AWS Cloud9 identity-based policies, see Identity-based policy examples for AWS Cloud9.

Policy resources for AWS Cloud9

Supports policy resources: Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Resource JSON policy element specifies the object or objects to which the action applies. Statements must include either a Resource or a NotResource element. As a best practice, specify a resource using its Amazon Resource Name (ARN). You can do this for actions that support a specific resource type, known as resource-level permissions.

For actions that don't support resource-level permissions, such as listing operations, use a wildcard (*) to indicate that the statement applies to all resources.

"Resource": "*"

To see a list of AWS Cloud9 resource types and their ARNs, see Resources defined by AWS Cloud9 in the Service Authorization Reference. To learn with which actions you can specify the ARN of each resource, see Actions defined by AWS Cloud9.

To view examples of AWS Cloud9 identity-based policies, see Identity-based policy examples for AWS Cloud9.

Policy condition keys for AWS Cloud9

Supports service-specific policy condition keys: Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Condition element (or Condition block) lets you specify conditions in which a statement is in effect. The Condition element is optional. You can create conditional expressions that use condition operators, such as equals or less than, to match the condition in the policy with values in the request.

If you specify multiple Condition elements in a statement, or multiple keys in a single Condition element, AWS evaluates them using a logical AND operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical OR operation. All of the conditions must be met before the statement's permissions are granted.

You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see IAM policy elements: variables and tags in the IAM User Guide.

AWS supports global condition keys and service-specific condition keys. To see all AWS global condition keys, see AWS global condition context keys in the IAM User Guide.

To see a list of AWS Cloud9 condition keys, see Condition keys for AWS Cloud9 in the Service Authorization Reference. To learn with which actions and resources you can use a condition key, see Actions defined by AWS Cloud9.

To view examples of AWS Cloud9 identity-based policies, see Identity-based policy examples for AWS Cloud9.

ACLs in AWS Cloud9

Supports ACLs: No

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

ABAC with AWS Cloud9

Supports ABAC (tags in policies): Yes

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. You can attach tags to IAM entities (users or roles) and to many AWS resources. Tagging entities and resources is the first step of ABAC. Then you design ABAC policies to allow operations when the principal's tag matches the tag on the resource that they are trying to access.

ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome.

To control access based on tags, you provide tag information in the condition element of a policy using the aws:ResourceTag/key-name, aws:RequestTag/key-name, or aws:TagKeys condition keys.

If a service supports all three condition keys for every resource type, then the value is Yes for the service. If a service supports all three condition keys for only some resource types, then the value is Partial.

For more information about ABAC, see What is ABAC? in the IAM User Guide. To view a tutorial with steps for setting up ABAC, see Use attribute-based access control (ABAC) in the IAM User Guide.

Using temporary credentials with AWS Cloud9

Supports temporary credentials: Yes

Some AWS services don't work when you sign in using temporary credentials. For additional information, including which AWS services work with temporary credentials, see AWS services that work with IAM in the IAM User Guide.

You are using temporary credentials if you sign in to the AWS Management Console using any method except a user name and password. For example, when you access AWS using your company's single sign-on (SSO) link, that process automatically creates temporary credentials. You also automatically create temporary credentials when you sign in to the console as a user and then switch roles. For more information about switching roles, see Switching to a role (console) in the IAM User Guide.

You can manually create temporary credentials using the AWS CLI or AWS API. You can then use those temporary credentials to access AWS. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see Temporary security credentials in IAM.

Forward access sessions for AWS Cloud9

Supports forward access sessions (FAS): Yes

When you use an IAM user or role to perform actions in AWS, you are considered a principal. When you use some services, you might perform an action that then initiates another action in a different service. FAS uses the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. FAS requests are only made when a service receives a request that requires interactions with other AWS services or resources to complete. In this case, you must have permissions to perform both actions. For policy details when making FAS requests, see Forward access sessions.

Service roles for AWS Cloud9

Supports service roles: Yes

A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see Creating a role to delegate permissions to an AWS service in the IAM User Guide.

Service-linked roles for AWS Cloud9

Supports service-linked roles: Yes

A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.

For details about creating or managing service-linked roles, see AWS services that work with IAM. Find a service in the table that includes a Yes in the Service-linked role column. Choose the Yes link to view the service-linked role documentation for that service.

Identity-based policy examples for AWS Cloud9

By default, users and roles don't have permission to create or modify AWS Cloud9 resources. They also can't perform tasks by using the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS API. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. The administrator can then add the IAM policies to roles, and users can assume the roles.

To learn how to create an IAM identity-based policy by using these example JSON policy documents, see Creating IAM policies in the IAM User Guide.

For details about actions and resource types defined by AWS Cloud9, including the format of the ARNs for each of the resource types, see Actions, resources, and condition keys for AWS Cloud9 in the Service Authorization Reference.

Policy best practices

Identity-based policies determine whether someone can create, access, or delete AWS Cloud9 resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:

For more information about best practices in IAM, see Security best practices in IAM in the IAM User Guide.

Using the AWS Cloud9 console

To access the AWS Cloud9 console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the AWS Cloud9 resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.

You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform.

To ensure that users and roles can still use the AWS Cloud9 console, also attach the AWS Cloud9 ConsoleAccess or ReadOnly AWS managed policy to the entities. For more information, see Adding permissions to a user in the IAM User Guide.

Allow users to view their own permissions

This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

Troubleshooting AWS Cloud9 identity and access

Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS Cloud9 and IAM.

I am not authorized to perform an action in AWS Cloud9

If you receive an error that you're not authorized to perform an action, your policies must be updated to allow you to perform the action.

The following example error occurs when the mateojackson IAM user tries to use the console to view details about a fictional my-example-widget resource but doesn't have the fictional awes:GetWidget permissions.

User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: awes:GetWidget on resource: my-example-widget

In this case, the policy for the mateojackson user must be updated to allow access to the my-example-widget resource by using the awes:GetWidget action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

I am not authorized to perform iam:PassRole

If you receive an error that you're not authorized to perform the iam:PassRole action, your policies must be updated to allow you to pass a role to AWS Cloud9.

Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.

The following example error occurs when an IAM user named marymajor tries to use the console to perform an action in AWS Cloud9. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

In this case, Mary's policies must be updated to allow her to perform the iam:PassRole action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

I want to allow people outside of my AWS account to access my AWS Cloud9 resources

You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.

To learn more, consult the following:

How AWS Cloud9 works with IAM resources and operations

AWS Identity and Access Management is used to manage the permissions that allow you to work with both AWS Cloud9 development environments and other AWS services and resources.

AWS Cloud9 resources and operations

In AWS Cloud9, the primary resource is an AWS Cloud9 development environment. In a policy, you use an Amazon Resource Name (ARN) to identify the resource that the policy applies to. The following table lists environment ARNs. For more information, see Amazon Resource Names (ARNs) and AWS Service Namespaces in the Amazon Web Services General Reference.

For example, you can indicate a specific environment in your statement using its Amazon Resource Name (ARN), as follows.

"Resource": "arn:aws:cloud9:us-east-2:123456789012:environment:70d899206236474f9590d93b7c41dfEX"

To specify all resources, use the wildcard character (*) in the Resource element.

"Resource": "*"

To specify multiple resources in a single statement, separate their Amazon Resource Names (ARNs) with commas.

"Resource": [
  "arn:aws:cloud9:us-east-2:123456789012:environment:70d899206236474f9590d93b7c41dfEX",
  "arn:aws:cloud9:us-east-2:123456789012:environment:81e900317347585a0601e04c8d52eaEX"
]

AWS Cloud9 provides a set of operations to work with AWS Cloud9 resources. For a list, see the AWS Cloud9 permissions reference.

Understanding resource ownership

The AWS account account owns the resources that are created in the account, regardless of who created the resources.

Consider the following use cases and scenarios:

Managing access to resources

A permissions policy describes who has access to which resources.

Policies attached to an IAM identity are referred to as identity-based policies (or IAM policies). Policies attached to a resource are referred to as resource-based policies. AWS Cloud9 supports both identity-based and resource-based policies.

Each of the following API actions requires only an IAM policy to be attached to the IAM identity that wants to call these API actions:

The following API actions require a resource-based policy. An IAM policy isn't required, but AWS Cloud9 uses an IAM policy if it's attached to the IAM identity that wants to call these API actions. The resource-based policy must be applied to the desired AWS Cloud9 resource:

For more information about what each of these API actions does, see the AWS Cloud9 API Reference.

You cannot attach a resource-based policy to an AWS Cloud9 resource directly. Instead, AWS Cloud9 attaches the appropriate resource-based policies to AWS Cloud9 resources as you add, modify, update, or delete environment members.

To grant a user permissions to perform actions on AWS Cloud9 resources, you attach a permissions policy to an IAM group that the user belongs to. We recommend that you attach an AWS managed (predefined) policy for AWS Cloud9 whenever possible. AWS managed policies contain predefined sets of access permissions for common usage scenarios and user types, such as full administration of an environment, environment users, and users who have only read-only access to an environment. For a list of AWS managed policies for AWS Cloud9, see AWS managed policies for AWS Cloud9.

For more detailed usage scenarios and unique user types, you can create and attach your own customer managed policies. See Additional setup options for AWS Cloud9 (team and enterprise) and Creating customer managed policies for AWS Cloud9.

To attach an IAM policy (AWS managed or customer managed) to an IAM identity, see Attaching IAM Policies (Console) in the IAM User Guide.

Session permissions for API operations

When using the AWS CLI or AWS API to programmatically create a temporary session for a role or federated user, you can pass session policies as a parameter to extend the scope of the role session. This means that the effective permissions of the session are the intersection of the role’s identity-based policies and the session policies.

When a request is made to access a resource during a session, if there's no applicable Deny statement but also no applicable Allow statement in the session policy, the result of the policy evaluation is an implicit denial. (For more information, see Determining whether a request is allowed or denied within an account in the IAM User Guide.)

But, for AWS Cloud9 API operations that require a resource-based policy (see above), permissions are granted to the IAM entity that's calling if it's specified as the Principal in the resource policy. This explicit permission takes precedence over the implicit denial of the session policy, thereby allowing the session to call the AWS Cloud9 API operation successfully.

AWS managed policies for AWS Cloud9

An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.

Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining customer managed policies that are specific to your use cases.

You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.

For more information, see AWS managed policies in the IAM User Guide.

AWS managed policy: AWSCloud9Administrator

You can attach the AWSCloud9Administrator policy to your IAM identities.

This policy grants administrative permissions that provide administrator access to AWS Cloud9.

Permissions details

This policy includes the following permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:*",
                "iam:GetUser",
                "iam:ListUsers",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "ec2:DescribeInstanceTypeOfferings",
                "ec2:DescribeRouteTables"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession",
                "ssm:GetConnectionStatus"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringLike": {
                    "ssm:resourceTag/aws:cloud9:environment": "*"
                },
                "StringEquals": {
                    "aws:CalledViaFirst": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/*"
            ]
        }
    ]
}

AWS managed policy: AWSCloud9User

You can attach the AWSCloud9User policy to your IAM identities.

This policy grants user permissions to create AWS Cloud9 development environments and to manage owned environments.

Permissions details

This policy includes the following permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:UpdateUserSettings",
                "cloud9:GetUserSettings",
                "iam:GetUser",
                "iam:ListUsers",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "ec2:DescribeInstanceTypeOfferings",
                "ec2:DescribeRouteTables"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:CreateEnvironmentEC2",
                "cloud9:CreateEnvironmentSSH"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "cloud9:OwnerArn": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:GetUserPublicKey"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "cloud9:UserArn": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:DescribeEnvironmentMemberships"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "Null": {
                    "cloud9:UserArn": "true",
                    "cloud9:EnvironmentId": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession",
                "ssm:GetConnectionStatus"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringLike": {
                    "ssm:resourceTag/aws:cloud9:environment": "*"
                },
                "StringEquals": {
                    "aws:CalledViaFirst": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/*"
            ]
        }
    ]
}

AWS managed policy: AWSCloud9EnvironmentMember

You can attach the AWSCloud9EnvironmentMember policy to your IAM identities.

This policy grants membership permissions that provide the ability to join an AWS Cloud9 shared environment.

Permissions details

This policy includes the following permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:GetUserSettings",
                "cloud9:UpdateUserSettings",
                "iam:GetUser",
                "iam:ListUsers"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:DescribeEnvironmentMemberships"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "Null": {
                    "cloud9:UserArn": "true",
                    "cloud9:EnvironmentId": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession",
                "ssm:GetConnectionStatus"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringLike": {
                    "ssm:resourceTag/aws:cloud9:environment": "*"
                },
                "StringEquals": {
                    "aws:CalledViaFirst": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/*"
            ]
        }
    ]
}

AWS managed policy: AWSCloud9ServiceRolePolicy

The service-linked role AWSServiceRoleForAWSCloud9 uses this policy to allow the AWS Cloud9 environment interact with Amazon EC2 and AWS CloudFormation resources.

Permissions details

The AWSCloud9ServiceRolePolicy grants the AWSServiceRoleForAWSCloud9 the necessary permissions to allow AWS Cloud9 to interact with the AWS services (Amazon EC2 and AWS CloudFormation) that are required to create and run development environments.

AWS Cloud9 defines the permissions of its service-linked roles, and only AWS Cloud9 can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.

For more information on how AWS Cloud9 uses service-linked roles, see Using service-linked roles for AWS Cloud9.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"ec2:RunInstances",
				"ec2:CreateSecurityGroup",
				"ec2:DescribeVpcs",
				"ec2:DescribeSubnets",
				"ec2:DescribeSecurityGroups",
				"ec2:DescribeInstances",
				"ec2:DescribeInstanceStatus",
				"cloudformation:CreateStack",
				"cloudformation:DescribeStacks",
				"cloudformation:DescribeStackEvents",
				"cloudformation:DescribeStackResources"
			],
			"Resource": "*"
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:TerminateInstances",
				"ec2:DeleteSecurityGroup",
				"ec2:AuthorizeSecurityGroupIngress"
			],
			"Resource": "*"
		},
		{
			"Effect": "Allow",
			"Action": [
				"cloudformation:DeleteStack"
			],
			"Resource": "arn:aws:cloudformation:*:*:stack/aws-cloud9-*"
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:CreateTags"
			],
			"Resource": [
				"arn:aws:ec2:*:*:instance/*",
				"arn:aws:ec2:*:*:security-group/*"
			],
			"Condition": {
				"StringLike": {
					"aws:RequestTag/Name": "aws-cloud9-*"
				}
			}
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:StartInstances",
				"ec2:StopInstances"
			],
			"Resource": "*",
			"Condition": {
				"StringLike": {
					"ec2:ResourceTag/aws:cloudformation:stack-name": "aws-cloud9-*"
				}
			}
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:StartInstances",
				"ec2:StopInstances"
			],
			"Resource": [
				"arn:aws:license-manager:*:*:license-configuration:*"
			]
		},
		{
			"Effect": "Allow",
			"Action": [
				"iam:ListInstanceProfiles",
				"iam:GetInstanceProfile"
			],
			"Resource": [
				"arn:aws:iam::*:instance-profile/cloud9/*"
			]
		},
		{
			"Effect": "Allow",
			"Action": [
				"iam:PassRole"
			],
			"Resource": [
				"arn:aws:iam::*:role/service-role/AWSCloud9SSMAccessRole"
			],
			"Condition": {
				"StringLike": {
					"iam:PassedToService": "ec2.amazonaws.com"
				}
			}
		}
	]
}

AWS Cloud9 updates to AWS managed policies

View details about updates to AWS managed policies for AWS Cloud9 since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the AWS Cloud9 Document history page.

Creating customer managed policies for AWS Cloud9

If none of the AWS managed policies meet your access control requirements, you can create and attach your own customer managed policies.

To create a customer managed policy, see Create an IAM Policy (Console) in the IAM User Guide.

Specifying policy elements: effects, principals, actions, and resources

For each AWS Cloud9 resource, the service defines a set of API operations. To grant permissions for these API operations, AWS Cloud9 defines a set of actions that you can specify in a policy.

The following are the basic policy elements:

To learn more about IAM policy syntax and descriptions, see the IAM JSON Policy Reference in the IAM User Guide.

For a table showing all of the AWS Cloud9 API actions and the resources they apply to, see the AWS Cloud9 permissions reference.

Customer managed policy examples

In this section, you can find example policies that grant permissions for AWS Cloud9 actions. You can adapt the following example IAM policies to allow or explicitly deny AWS Cloud9 access for your IAM identities.

To create or attach a customer managed policy to an IAM identity, see Create an IAM Policy (Console) and Attaching IAM Policies (Console) in the IAM User Guide.

Get information about environments

The following example IAM policy statement, attached to an IAM entity, allows that entity to get information about any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:DescribeEnvironments",
      "Resource": "*"
    }
  ]
}

Create EC2 environments

The following example IAM policy statement, attached to an IAM entity, allows that entity to create AWS Cloud9 EC2 development environments in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:CreateEnvironmentEC2",
      "Resource": "*"
    }
  ]
}

Create EC2 environments with specific Amazon EC2 instance types

The following example IAM policy statement, attached to an IAM entity, allows that entity to create AWS Cloud9 EC2 development environments in their account. However, EC2 environments can use only the specified class of Amazon EC2 instance types.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:CreateEnvironmentEC2",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "cloud9:InstanceType": "t3.*"
        }
      }
    }
  ]
}

Create EC2 environments in specific Amazon VPC subnets

The following example IAM policy statement, attached to an IAM entity, allows that entity to create AWS Cloud9 EC2 development environments in their account. However, EC2 environments can use only the specified Amazon VPC subnets.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:CreateEnvironmentEC2",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "cloud9:SubnetId": [
            "subnet-12345678",
            "subnet-23456789"
          ]
        }
      }
    }
  ]
}

Create an EC2 environments with a specific environment name

The following example IAM policy statement, attached to an IAM entity, allows that entity to create an AWS Cloud9 EC2 development environment in their account. However, the EC2 environment can use only the specified name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:CreateEnvironmentEC2",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "cloud9:EnvironmentName": "my-demo-environment"
        }
      }
    }
  ]
}

Create SSH environments only

The following example IAM policy statement, attached to an IAM entity, allows that entity to create AWS Cloud9 SSH development environments in their account. However, the entity can't create AWS Cloud9 EC2 development environments.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:CreateEnvironmentSSH",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "cloud9:CreateEnvironmentEC2",
      "Resource": "*"
    }
  ]
}

Update environments or prevent updating an environment

The following example IAM policy statement, attached to an IAM entity, allows that entity to change information about any AWS Cloud9 development environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:UpdateEnvironment",
      "Resource": "*"
    }
  ]
}

The following example IAM policy statement, attached to an IAM entity, explicitly prevents that entity from changing information about the environment with the specified Amazon Resource Name (ARN).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "cloud9:UpdateEnvironment",
      "Resource": "arn:aws:cloud9:us-east-2:123456789012:environment:81e900317347585a0601e04c8d52eaEX"
    }
  ]
}

Get lists of environment members

The following example IAM policy statement, attached to an IAM entity, allows that entity to get a list of members for any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:DescribeEnvironmentMemberships",
      "Resource": "*"
    }
  ]
}

Share environments only with a specific user

The following example IAM policy statement, attached to an IAM entity, allows that entity to share any environment in their account with only the specified user.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloud9:CreateEnvironmentMembership"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "cloud9:UserArn": "arn:aws:iam::123456789012:user/MyDemoUser"
        }
      }
    }
  ]
}

Prevent sharing environments

The following example IAM policy statement, attached to an IAM entity, prevents that entity from sharing any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloud9:CreateEnvironmentMembership",
        "cloud9:UpdateEnvironmentMembership"
      ],
      "Resource": "*"
    }
  ]
}

Change, or prevent changing, the settings of environment members

The following example IAM policy statement, attached to an IAM entity, allows that entity to change the settings of members in any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:UpdateEnvironmentMembership",
      "Resource": "*"
    }
  ]
}

The following example IAM policy statement, attached to an IAM entity, explicitly prevents that entity from changing the settings of members in the environment with the specified Amazon Resource Name (ARN).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "cloud9:UpdateEnvironmentMembership",
      "Resource": "arn:aws:cloud9:us-east-2:123456789012:environment:81e900317347585a0601e04c8d52eaEX"
    }
  ]
}

Remove, or prevent removing, environment members

The following example IAM policy statement, attached to an IAM entity, allows that entity to remove any member from any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:DeleteEnvironmentMembership",
      "Resource": "*"
    }
  ]
}

The following example IAM policy statement, attached to an IAM entity, explicitly prevents that entity from removing any member from the environment with the specified Amazon Resource Name (ARN).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "cloud9:DeleteEnvironmentMembership",
      "Resource": "arn:aws:cloud9:us-east-2:123456789012:environment:81e900317347585a0601e04c8d52eaEX"
    }
  ]
}

Delete, or prevent deleting, an environment

The following example IAM policy statement, attached to an IAM entity, allows that entity to delete any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloud9:DeleteEnvironment",
      "Resource": "*"
    }
  ]
}

The following example IAM policy statement, attached to an IAM entity, explicitly prevents that entity from deleting the environment with the specified Amazon Resource Name (ARN).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "cloud9:DeleteEnvironment",
      "Resource": "arn:aws:cloud9:us-east-2:123456789012:environment:81e900317347585a0601e04c8d52eaEX"
    }
  ]
}

Custom IAM policy for SSM environment creation

There is a current permissions issue that occurs when creating an SSM environment with the AWSCloud9Administrator or AWSCloud9User policies attached. The following example IAM policy statement, when attached to an IAM entity, enables users to attach and use either the AWS managed policy AWSCloud9Administrator or AWSCloud9User.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:UpdateUserSettings",
                "cloud9:GetUserSettings",
                "iam:GetUser",
                "iam:ListUsers",
                "iam:ListRoles",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "ec2:DescribeRouteTables"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:CreateEnvironmentEC2",
                "cloud9:CreateEnvironmentSSH"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "cloud9:OwnerArn": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:GetUserPublicKey"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "cloud9:UserArn": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloud9:DescribeEnvironmentMemberships"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "Null": {
                    "cloud9:UserArn": "true",
                    "cloud9:EnvironmentId": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringLike": {
                    "ssm:resourceTag/aws:cloud9:environment": "*"
                },
                "StringEquals": {
                    "aws:CalledViaFirst": "cloud9.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": ["iam:ListInstanceProfilesForRole", "iam:CreateRole"],
            "Resource": ["arn:aws:iam::*:role/service-role/AWSCloud9SSMAccessRole"]
        },
        {
            "Effect": "Allow",
            "Action": ["iam:AttachRolePolicy"],
            "Resource": ["arn:aws:iam::*:role/service-role/AWSCloud9SSMAccessRole"],
            "Condition": {
                "StringEquals": {
                    "iam:PolicyARN": "arn:aws:iam::aws:policy/AWSCloud9SSMInstanceProfile"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::*:role/service-role/AWSCloud9SSMAccessRole",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateInstanceProfile",
                "iam:AddRoleToInstanceProfile"
            ],
            "Resource": [
                "arn:aws:iam::*:instance-profile/cloud9/AWSCloud9SSMInstanceProfile"
            ]
        }
    ]
}

AWS Cloud9 permissions reference

You can use AWS wide condition keys in your AWS Cloud9 policies to express conditions. For a list, see IAM JSON Policy Elements: Condition in the IAM User Guide.

You specify the actions in the policy's Action field. To specify an action, use the cloud9: prefix followed by the API operation name (for example, "Action": "cloud9:DescribeEnvironments"). To specify multiple actions in a single statement, separate them with commas (for example, "Action": [ "cloud9:UpdateEnvironment", "cloud9:DeleteEnvironment" ]).

Using wildcard characters

You specify an ARN, with or without a wildcard character (*), as the resource value in the policy's Resource field. You can use a wildcard to specify multiple actions or resources. For example, cloud9:* specifies all AWS Cloud9 actions and cloud9:Describe* specifies all AWS Cloud9 actions that begin with Describe.

The following example allows an IAM entity to get information about environments and environment memberships for any environment in their account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloud9:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

AWS Cloud9 API operations and required permissions for actions

AWS managed temporary credentials

For an AWS Cloud9 EC2 development environment, AWS Cloud9 makes temporary AWS access credentials available to you in the environment. We call these AWS managed temporary credentials. This provides the following benefits:

Here's how AWS managed temporary credentials work whenever an EC2 environment tries to access an AWS service on behalf of an AWS entity (for example, an IAM user):

The owner of an EC2 environment can turn on or off AWS managed temporary credentials for that environment at any time, as follows:

If you turn off AWS managed temporary credentials, the environment cannot access any AWS services, regardless of the AWS entity who makes the request. But, suppose that you can't or don't want to turn on AWS managed temporary credentials for an environment, and you still need the environment to access AWS services. Then, consider the following alternatives:

The preceding alternatives override all permissions that are allowed (or denied) by AWS managed temporary credentials in an EC2 environment.

Actions supported by AWS managed temporary credentials

For an AWS Cloud9 EC2 development environment, AWS managed temporary credentials allow all AWS actions for all AWS resources in the caller's AWS account, with the following restrictions:

If AWS Cloud9 doesn't support an action or resource that you need an EC2 environment to access, or if AWS managed temporary credentials is turned off for an EC2 environment and you can't turn it back on, consider the following alternatives:

The preceding alternatives override all permissions that are allowed (or denied) by AWS managed temporary credentials in an EC2 environment.

Creating and updating AWS managed temporary credentials

For an AWS Cloud9 EC2 development environment, AWS managed temporary credentials are created the first time you open the environment.

AWS managed temporary credentials are updated under any of the following conditions:

Controlling access to AWS managed temporary credentials

A collaborator with AWS managed temporary credentials can use AWS Cloud9 to interact with other AWS services. To ensure that only trusted collaborators are provided with AWS managed temporary credentials, these credentials are disabled if a new member is added by anyone other than the environment owner. The credentials are disabled by the deletion of the ~/.aws/credentials file.

Only the environment owner can re-enable AWS managed temporary credentials so that they can be shared with other members. When the environment owner opens the IDE, a dialog box confirms that AWS managed temporary credentials are disabled. The environment owner can re-enable the credentials for all members or keep them disabled for all members.