New Resource-Level Permissions for AWS OpsWorks

My colleague Chris Barclay reports on an important new feature for AWS OpsWorks!

— Jeff;

I am pleased to announce that AWS OpsWorks now supports resource-level permissions. AWS OpsWorks is an application management service that lets you provision resources, deploy and update software, automate common operational tasks, and monitor the state of your environment. You can optionally use the popular Chef automation platform to extend OpsWorks using your own custom recipes.

With resource-level permissions you can now:

• Grant users access to specific stacks, making management of multi-user environments easier. For example, you can give a user access to the staging and production stacks but not the secret stack.
• Set user-specific permissions for actions on each stack, allowing you to decide who can deploy new application versions or create new resources on a per-stack basis for example.
• Delegate management of each OpsWorks stack to a specific user or set of users.
• Control user-level SSH access to Amazon EC2 instances, allowing you to instantly grant or remove access to instances for individual users.

A simple user interface in OpsWorks lets you select a policy for each user on each stack depending on the level of control needed:

• Deny blocks the users access to this stack.
• IAM Policies Only bases a users permissions exclusively on policies attached to the user in IAM.
• Show combines the users IAM policies with permissions that provide read-only access to the stacks resources.
• Deploy combines the users IAM policies with Show permissions and permissions that let the user deploy new application versions.
• Manage combines the users IAM policies with permissions that provide full control of this stack.

These policies make it easy to quickly configure a user with the right permissions for the tasks they need to accomplish. You can also create a custom IAM policy to fine-tune their permissions.

Lets see this in action. In this example we have two users defined in the IAM console: Chris and Mary.

Lets give Chris the AWS OpsWorks Full Access policy; Mary doesnt need any IAM policy to use OpsWorks.

Now go to the OpsWorks console, open the Users view, and import Chris and Mary.

You can then go to a stack and open the Permissions view to designate OpsWorks permissions for each user. Give Mary Manage permissions for the MyWebService stack. Chris should already be able to access this stack because you attached the AWS OpsWorks Full Access policy to his user in IAM.

To remove Chris access to this stack, simply select the Deny radio button next to Chris. Your Permissions view will now look like this:

Chris can no longer view or access the stack because the explicit Deny overrides his users AWS OpsWorks Full Access policy. Mary can still access the stack and she can create, manage and delete resources.

But assume that this is a production stack and you dont want Mary to be able to stop instances. To make sure she cant do that, you can create a custom policy in the IAM console.

Go to the IAM console, select the user Mary and then click Attach User Policy. Add this custom policy:

What does this policy mean? Here are the pieces:

• “Action”: “opsworks:Stop*” means this applies to any OpsWorks API action that begins with Stop.
• “Effect”: “Deny” tells OpsWorks to deny that action request.
• “Resource”: “arn:aws:opsworks:*:*:stack/2860c9c8-9d12-4cc1-aed1-xxxxxxxx” specifies that this statement applies only to resources in the specified stack. If Mary was using other stacks, this policy would not apply and she could perform stop actions if she had Manage access.

After applying the policy, you can return to the OpsWorks console and view a running instance as user Mary.

You can see that Mary can no longer stop this instance.

Behind the scenes, a users OpsWorks and IAM permissions are merged and then evaluated to determine whether a request is allowed or denied. In Marys case, the Manage user policy that you applied in OpsWorks allows her to stop instances in that stack. However, the explicit Deny on Stop* actions in her IAM user policy overrides the Allow in her OpsWorks policy. To learn more about policy evaluation, see the IAM documentation.

Once the users action has been evaluated, OpsWorks carries out the request. The user doesnt actually need permissions to use underlying services such as Amazon EC2 you give those permissions to the OpsWorks service role. This gives you control over how resources are administered without requiring you to manage user permissions to each of the underlying services. For example, a policy in IAM might deny Mary the ability to create instances within EC2 (either explicitly, or by simply not giving her explicit permission to do so). But Marys OpsWorks Manage policy allows her to create instances within an OpsWorks stack. Since you can define the region and VPC that each stack uses, this can help you comply with organizational rules on where instances can be launched.

Resource-level permissions give you control and flexibility for how to manage your applications. Try it and let us know what you think! For more information, please see the OpsWorks documentation.

— Chris Barclay, Senior Product Manager