What are policies? - AWS RoboMaker
Identity-based policies Policy access level classifications

End of support notice: On September 10, 2025, AWS will discontinue support for AWS RoboMaker. After September 10, 2025, you will no longer be able to access the AWS RoboMaker console or AWS RoboMaker resources. For more information on transitioning to AWS Batch to help run containerized simulations, visit this blog post.

What are policies?

You control access in AWS by creating policies and attaching them to IAM identities or AWS resources.

Note

To get started quickly, review the introductory information on Authentication and access control for AWS RoboMaker and then see Getting started with IAM.

A policy is an object in AWS that, when associated with an entity or resource, defines their permissions. AWS evaluates these policies when a principal, such as a user, makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents.

IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, if a policy allows the GetUser action, then a user with that policy can get user information from the AWS Management Console, the AWS CLI, or the AWS API. When you create an IAM user, you can set up the user to allow console or programmatic access. The IAM user can sign in to the console using a user name and password. Or they can use access keys to work with the CLI or API.

To provide access, add permissions to your users, groups, or roles:

Unsupported policies with AWS RoboMaker

Resource-based policies and Access control lists (ACLs) are not supported by AWS RoboMaker. For more information, see Policy types in the IAM User Guide.

Identity-based policies

You can attach policies to IAM identities. For example, you can do the following:

  • Attach a permissions policy to a user or a group in your account – To grant a user permissions to create an AWS RoboMaker resource, such as a robot applications, you can attach a permissions policy to a user or a group to which the user belongs.

  • Attach a permissions policy to a role (grant cross-account permissions) – You can attach an identity-based permissions policy to an IAM role to grant cross-account permissions. For example, the administrator in account A can create a role to grant cross-account permissions to another AWS account (for example, account B) or an AWS service as follows:

    1. Account A administrator creates an IAM role and attaches a permissions policy to the role that grants permissions on resources in account A.

    2. Account A administrator attaches a trust policy to the role identifying account B as the principal who can assume the role.

    3. Account B administrator can then delegate permissions to assume the role to any users in account B. Doing this allows users in account B to create or access resources in account A. The principal in the trust policy can also be an AWS service principal if you want to grant an AWS service permissions to assume the role.

    For more information about using IAM to delegate permissions, see Access Management in the IAM User Guide.

For more information about users, groups, roles, and permissions, see Identities (Users, Groups, and Roles) in the IAM User Guide.

Policy access level classifications

In the IAM console, actions are grouped using the following access level classifications:

  • List – Provide permission to list resources within the service to determine whether an object exists. Actions with this level of access can list objects but cannot see the contents of a resource. Most actions with the List access level cannot be performed on a specific resource. When you create a policy statement with these actions, you must specify All resources ("*").

  • Read – Provide permission to read but not edit the contents and attributes of resources in the service. For example, the Amazon S3 actions GetObject and GetBucketLocation have the Read access level.

  • Write – Provide permission to create, delete, or modify resources in the service. For example, the Amazon S3 actions CreateBucket, DeleteBucket and PutObject have the Write access level.

  • Permissions management – Provide permission to grant or modify resource permissions in the service. For example, most IAM and AWS Organizations policy actions have the Permissions management access level.

    Tip

    To improve the security of your AWS account, restrict or regularly monitor policies that include the Permissions management access level classification.

  • Tagging – Provide permission to create, delete, or modify tags that are attached to a resource in the service. For example, the Amazon EC2 CreateTags and DeleteTags actions have the Tagging access level.