Announcing Resource-Level Permissions for AWS OpsWorks

We are 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.

IAM lets you create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources. With this release, IAM administrators can add OpsWorks stack resources to user policies in the IAM console. If you manage applications in OpsWorks, you can use a simple user interface in the OpsWorks console to select what each IAM user can do on each OpsWorks stack depending on the level of control needed:

• Deny blocks the user’s access to this stack.
• IAM Policies Only bases a user’s permissions exclusively on policies attached to the user in IAM.
• Show combines the user’s IAM policies with permissions that provide read-only access to the stack’s resources.
• Deploy combines the user’s IAM policies with Show permissions and permissions that let the user deploy new application versions.
• Manage combines the user’s IAM policies with permissions that provide full control of this stack.You can also augment the policy defined in the OpsWorks console with a custom IAM policy to fine-tune a user’s permissions.

Note: the Show, Deploy, and Manage stack permissions can only be configured from the OpsWorks console. These permissions cannot be created/modified from within the IAM console.

Let’s see this in action. In this example, we have two users originally created in the IAM console: Chris and Mary.

Let’s give Chris the AWS OpsWorks Full Access policy; Mary doesn’t need any policy defined in the IAM console to use OpsWorks.

Now go to the OpsWorks console, open the Users view, and import Chris and Mary. Note that only users with AWS OpsWorks Full Access permissions can import users.

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.

If Chris left the project and you want to remove Chris’s 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 user’s AWS OpsWorks Full Access IAM 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 don’t want Mary to be able to stop instances. To make sure she can’t do that, 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 user’s OpsWorks and IAM permissions are merged and then evaluated to determine whether a request is allowed or denied. In Mary’s 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 user’s action has been evaluated, OpsWorks carries out the request. The user doesn’t 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 Mary’s 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 in our Forums! For more information, please see the OpsWorks documentation.

– Ben