How I Stopped Worrying and Learned to Give Myself Any AWS Permissions I Wanted
I'm happy to have some ideas worth blogging about at last! Here's a really big one I stumbled across if you're in an organization that wants to keep permissions relatively locked down on AWS (in terms of performing actions on resources), but still wants to enable individual users the ability to interact with their own stacks as needed without waiting on admins.
The TL/DR Of It
Using AWS CloudFormation, you can deploy a stack consisting of a single resource. This resource is of type AWS::IAM::ManagedPolicy. Attach all the policy statements you want, then add Users consisting of any IAM users on the AWS account. Voila, instant permissions to do whatever.
More About the Process
Let's say you need to tweak various aspects of your AWS setup. Maybe you have a DynamoDB entry that needs to be manually tweaked, a Lambda function where the concurrency needs to be adjusted, an SQS queue where the maximum age of a message needs to be adjusted, or files sitting around in an S3 bucket that are disrupting your Glue crawlers from processing the data into Athena or Redshift Spectrum correctly. Doing any of these (and more) can be difficult if you use CloudFormation (or some other infrastructure-as-code) to set up the resources, but then do not have permissions on the console to make adjustments to deal with emergent situations. Maybe you're uncertain that a deployment would disrupt everything in your queue, cost a bunch of time to redeploy code that doesn't actually need redeployment, etc. Or, you're having to work late or over the weekend, and aren't able to bother any admins who are able to help you adjust the dials.
The process of deploying such a CloudFormation template is pretty simple. In the Resources section of your CloudFormation template, define an AWS::IAM::ManagedPolicy resource. In your PolicyDocument, define an array of Statements that list a series of Actions you Allow on one or more Resources. If you have different actions you want to perform on different resources, simply add another item in the Statement array with its own Sid and other parameters. Finally, on the same level as your PolicyDocument, you will define Users consisting of IAM users belonging to the AWS account.
For example, if your team needs access to modify/access records on your DynamoDB, and to modify the provisioned concurrency for a Lambda function, you could write the following document:
Parameters:
MyTable:
Description: Name of the DynamoDB table
Type: String
Resources:
MyTeamPermissionPolicy:
Type: 'AWS::IAM::ManagedPolicy'
Properties:
PolicyDocument:
MyLambda:
Description: Name of the Lambda function
Type: String
MyTeamPermissionPolicy:
Type: 'AWS::IAM::ManagedPolicy'
Properties:
PolicyDocument:
Version: `2012-10-17'
Statement:
- Sid: AllowTeamDynamoPermissions
Effect: Allow
Action:
- "dynamodb:GetItem"
- "dynamodb:PutItem"
- "dynamodb:UpdateItem"
- "dynamodb:DeleteItem"
- "dynamodb:Query"
- "dynamodb:BatchWriteItem"
- "dynamodb:BatchGetItem"
- "dynamodb:Scan"
Resource:
- !Sub "arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${MyTable}"
- !Sub "arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${MyTable}/index/*"
- Sid: AllowTeamLambdaConcurrencyAdjustments
Effect: Allow
Action: "lambda:PutFunctionConcurrency"
Resource: !Sub "arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function/${MyLambda}"
Users:
- "alice.cooper"
- "bob.marley"
- "carole.king"
Assuming those three esteemed and eclectic performers have IAM users set up on your AWS account, you would be able to take this YAML code, create a Stack out of it in CloudFormation, and grant them access to perform these actions on these resources, which might clear their path to perform actions that were otherwise not granted by the admins. Additional permissions can be granted as they come up as error messages from the AWS console or CLI.
Use at your own risk!
Comments
Post a Comment