|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
One way to handle AWS OpsWorks permissions is to attach to every user an IAM policy that is based on the AWS OpsWorks Full Access template. However, this policy allows users to perform every AWS OpsWorks action on every stack. It is often desirable instead to restrict AWS OpsWorks users to a specified set of actions or set of stack resources. You can control AWS OpsWorks user permissions in two ways: By using the AWS OpsWorks Permissions page and by attaching an appropriate IAM policy.
The OpsWorks Permissions page—or the equivalent CLI or API actions—allows you to control user permissions in a multiuser environment on a per-stack basis by assigning each user one of several permission levels. Each level grants permissions for a standard set of actions for a particular stack resource. Using the OpsWorks Permissions page, you can control the following:
Who can access each stack.
Which actions each user is allowed to perform on each stack.
For example, you can allow some users to only view the stack while others can deploy applications, add instances, and so on.
Who can manage each stack.
You can delegate management of each stack to one or more specified users.
Who has user-level SSH access and sudo privileges on each stack's Amazon EC2 instances.
You can instantly grant or remove these permissions separately for each user.
You can also use the IAM console or API to attach policies to your users that grant explicit permissions for the various AWS OpsWorks resources and actions. Using an IAM policy to specify permissions is more flexible than using the permissions levels. It also allows you to set up IAM groups, which grant permissions to groups of users, or define roles that can be associated with federated users. An IAM policy is the only way to grant permissions for certain key AWS OpsWorks actions, such as creating or cloning stacks.
The two approaches are not mutually exclusive, and it is sometimes useful to combine them; AWS OpsWorks then evaluates both sets of permissions. For example, suppose you want to allow users to add or delete instances, but not add or delete layers. None of the permission levels on the AWS OpsWorks Permissions page support that specific set of permissions. However, you can use the Permissions page to grant users a Manage permission level, which allows them to perform most stack operations, and then attach an IAM policy that denies permissions to add or remove layers. For more information, see Overview of AWS IAM Permissions.
The following is a typical model for managing user permissions. In each case, the reader (you) is assumed to be an administrative user.
Use the IAM console to attach AWS OpsWorks Full Access policies to one or more administrative users.
Create an IAM user for each nonadministrative user with a policy that grants no AWS OpsWorks permissions.
If a user requires access only to AWS OpsWorks, you might not need to attach a policy at all. You can instead manage those permissions with the AWS OpsWorks Permissions page.
Use the AWS OpsWorks Users page to import the nonadministrative users into AWS OpsWorks.
For each stack, use the stack's Permissions page to assign a permission level to each user.
As needed, customize users' permission levels by attaching an appropriately configured IAM policy.
As a best practice, don't use root (account owner) credentials to perform everyday work in AWS. Instead, create an IAM administrators group with appropriate permissions. Then create IAM users for the people in your organization who need to perform administrative tasks (including for yourself), and add those users to the administrative group. For more information, see IAM Best Practices in the Using IAM guide.