- Who can access a resource
- What actions individuals or groups can perform with the resource
Every user starts with no permissions at all. In other words, a user can't do anything, not even view security settings or use access keys to interact with a resource. This is a good practice because it means that you can't inadvertently create a user with administrator rights simply because you forget to assign the user specific permissions.
Of course, assigning every user every permission required to perform what amounts to the same tasks is time consuming and error prone. A policy is a package of permissions that applies to a certain group of people. AWS comes with only the AdministratorAccess policy configured, so if you want to use other policies, you must define them yourself.Fortunately, policies come in several forms to make them easier to work with. The following list describes the policy types and describes how you use them:
- Managed: Stand-alone policies that you can attach to users and groups, but not to resources. A managed policy affects identities only. When creating a managed policy, you use a centralized management page to create, edit, monitor, roll back, and delegate policies. You have access to two kinds of managed policies.
- AWS-Managed: A policy that AWS creates and manages for you. These policies tend to support obvious needs that most organizations have. The reasons to use AWS managed policies are that they're simple to implement and they automatically change to compensate for changes to AWS functionality.
- Customer-Managed: A policy that you create and manage. Use these policies to support any special organizational requirements. The main reason to use a policy of this type is to gain flexibility that the AWS-managed option doesn't provide.
- Inline: Embedded policies that you create and attach to users, groups, or resources on an individual basis (without using a centralized manager). AWS views identity policies (those used for users and groups) differently from resource policies as described in the following list:
- Embedded User, Group, or Role: An identity policy that you embed directly into a user, group, or role. You use an identity policy to define the actions that an entity can perform. For example, a user can have permission to run instances of EC2. In some cases, in addition to defining what action a user can take, the policy can also define the specific resource with which the user can work. This additional level of control is a resource-level permission, one that defines both the action and the specific resource.
- Resource: One or more permissions that determine who can access the resource and what actions they can perform with it. You can add resource-based permissions to Amazon S3 buckets, Amazon Glacier vaults, Amazon SNS topics, Amazon SQS queues, and AWS Key Management Service encryption keys. Unlike policies created for identities, resource-based permissions are unmanaged (inline only).