-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minimum AWS policies for example. #244
Comments
Yeah, this is a really good one that definitely needs addressing. I'm actually not super sure. It's very liberal out of the gate, but it absolutely needs a way to run in a minimum-permissions kinda way. Let's see. For the execution policy, I think this is all that's necessary: ASSUME_POLICY = """{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"apigateway.amazonaws.com",
"lambda.amazonaws.com",
"events.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}""" and for the attach policy: ATTACH_POLICY = """{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": "arn:aws:logs:YOUR_LOG_RESOURCE_ARN"
},
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:YOUR_LAMBDA_FUNCTION_ARN"
]
},
]
}""" Plus permissions for whatever AWS resources you're using on top of that. Don't quote me on that, but that's my first guess. Leaving this ticket open until we can figure this out and get it documented. |
Related #241 |
Thanks! I'll start working with that and see where that can get me. |
Great! Please report back with what you find out so we can add it to the documentation. |
This is what I've learned so far (note: I am not an AWS expert) from adding actions on errors while deploying.
|
Ah okay, nice. I think you can probably remove "iam:PutRolePolicy" once you On Sun, Aug 14, 2016 at 3:11 PM, Wesley Kerr [email protected]
|
Does logging work with that? ex zappa tail |
I need to try that. I will give it a try tomorrow. |
The only thing I had to add in addition to @wesleykerr's doc above is {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::nameofmybucket"
]
},
{
"Effect": "Allow",
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject",
"s3:CreateMultipartUpload",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:ListBucketMultipartUploads"
],
"Resource": [
"arn:aws:s3:::nameofmybucket/*"
]
}
]
} |
Thanks for reporting your findings, @smoll . Can you try |
When I do
Edit: looks like |
I started noticing a lot of these in CI:
and I saw lots of duplicate keep warm schedules in the Lambda > Triggers tab. I believe adding |
I kept getting errors with the basic flask formation until I included cloudformation permissions.
|
To add to this conversation, I used CloudTrail to log AWS operations issued by Zappa during an app deploy and update. Below you'll find the list. This list, and the following process, might be useful for you. To repeat:
Once the logs were in my bucket, I downloaded them like this:
Then I issued this oneliner with jq to capture the user, service and operation. Then I grepped for the "zappadeployer" user (could've used jq, but ran out of time to figure it out) and counted unique occurrences. Here's what I see (account number redacted):
(I may have also tried to delete the deployed app, I don't remember.) Hope that helps. |
Well, if someone have no idea where to add the policies... Go to "https://console.aws.amazon.com/iam/home#/users", and find the user that you want to modify, click it. Then you will go to "https://console.aws.amazon.com/iam/home#/users/[YOUR-USER-NAME]", in the "Permissions" panel, there is a button on the bottom "Add inline policy". Click this, and you will go to some "Set Permission" page, choose "Custom Policy", and click "Select". Set whatever name you like... And paste the your policies into that new file. Updated Luckily, refering to MihaZelnik's answer, i finally found the policies working for me.
|
@ysong-sc You're welcome. Some words of caution: Attaching the the AWS-managed policy "AdministratorAccess" to a user gives unlimited access. See here for an explanation of the "AdministratorAccess" managed policy: http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html The inline policy you added in the previous step (which has a few "Allow" rules) is superseded by "AdministratorAccess". While the unlimited access granted by the policy "AdministratorAccess" will make Zappa work, this policy should be attached to a user in exceptional cases. Following the principle of least privilege, I do not recommend attaching this policy to users of limited operations, like deployments. See this document: http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html My hope is that the process (and report) can be used to craft a limited policy for Zappa. |
This is working for me
Edit: I added "route53:ListHostedZones", "route53:ChangeResourceRecordSets", "route53:GetHostedZone" for Let's Encrypt |
It's great to see development in narrowing AWS polices for Zappa (and serverless). If nobody beats me to it, I'll script a python implementation of @aimichal's CloudTrail technique to work out the minimal policies and turn them into a policy document. But that's for 2017. Happy holidays. |
I fall into the error report by @smoll |
@ysong-sc Your updated policy worked well for me. Saved me a lot of time. Thanks! 👍 |
I just got some permissions errors when using the latest policy above in travis - think its because Im now using VPC config to run the lambda functions with subnets and security groups... I needed to add: ec2:DescribeSecurityGroups |
For all the copy+paste people out there (like me!) the above permissions have a typo, DescibeSubnets should be DescribeSubnets. Change to: |
updated now @eely22 ..sorry! |
Would be great for us to find a way to build deployment automation of these Zappa deployment permissions. CloudFormation template? |
In what sense? Do you need them to be dynamically managed? You can use the My other longer-term plan is to steal the AST-parsing IAM-generator from Chalice. Possibly related: #634 |
Could zappa itself only set the above minimal policy? I was surprised that it gave itself basically wildcard permissions. While folks could hardcode their policy using |
Cool, I put it up in PR #894 |
For anyone who comes here, with version 0.43, I needed to add |
If you, like myself, have clients that won't let you set up too permissive policies on their AWS accounts, then you might want to take away "iam:PutRolePolicy" and add to your
Then attach to your IAM user one of the inline policies proposed here. Only make sure that at least the following two statements are there:
These will essentially let the Finally, since Zappa won't manage roles automatically, then you must manually create a service role to the default name:
Or name it something else in your settings files under the key Then edit the role's trust relationship as follows:
If your head is about to blow off with this, then don't panic, read this first and come back to here, things will become much more clear: https://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/ |
An authoritative how to on this with working Zappa policies to allow deployment with manual init would be great. Till then I have to use throwaway accounts to fiddle with Zappa. |
I think the permissions issue has to be addressed in the broader context for example multiple users, how the IAM roles and lambda function will have access to rest of AWS infrastructure and so on. People could look at DuploCloud platform ([https://portal.duplocloud.net]) which helps address this. I have written a tutorial on how one can use zappa to deploy a python application in AWS using DuploCloud platform, w/o worrying about any permissions stuff. The user does not even need a AWS account on his own... |
Minor feedback on the policy offered by audiolion May 24th. |
This feature request could be supported by implementing #1540 |
Does Zappa perform certain activities on an hourly or similar basis? I am trying to get the minimum permissions setup, but it seems that my app only works for a few hours, then it fails ( EDIT:
|
Hi @ameenmaali . Why it's different with |
Hey @toughrogrammer, I actually was not aware of that role when I was setting this up. But it looks like that would work, although I'd have to test to verify. It's been a while since I tested, but I remember testing with only some of the |
Just used this successfully.
|
Needed to add "cloudfront:UpdateDistribution" to the |
hey @andytwoods , thanks for the post . Did you make any changes on top of it or is this the final version ..? |
@rakekris I got the above initially but then moved over to "manage_roles": true. |
I followed @joarleymoraes example and some combinations of the policy statements here to come up with the following that works using Here is the role's inline policy:
Here is the role's trust relationship policy:
Since my lambda's are accessing resources in a VPC, I also had to attach the AWSLambdaVPCAccessExecutionRole policy to the role. I seem to be able to deploy, certify, undeploy, and tail using this. Edit: I had to also attach the AWSLambdaBasicExecutionRole policy to the role to allow creation of cloudwatch streams and logging to them. |
At the time of writing this comment ( {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:GetRole",
"iam:CreateRole",
"iam:PassRole",
"iam:PutRolePolicy"
],
"Resource": [
"arn:aws:iam::<ACCOUNT_ID>:role/*-ZappaLambdaExecutionRole"
]
},
{
"Effect": "Allow",
"Action": [
"apigateway:DELETE",
"apigateway:GET",
"apigateway:PATCH",
"apigateway:POST",
"apigateway:PUT",
"events:DeleteRule",
"events:DescribeRule",
"events:ListRules",
"events:ListRuleNamesByTarget",
"events:ListTargetsByRule",
"events:PutRule",
"events:PutTargets",
"events:RemoveTargets",
"lambda:AddPermission",
"lambda:CreateFunction",
"lambda:DeleteFunction",
"lambda:GetAlias",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetPolicy",
"lambda:InvokeFunction",
"lambda:ListVersionsByFunction",
"lambda:RemovePermission",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:DescribeStackResource",
"cloudformation:DescribeStacks",
"cloudformation:ListStackResources",
"cloudformation:UpdateStack",
"logs:DeleteLogGroup",
"logs:DescribeLogStreams",
"logs:FilterLogEvents"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Resource": [
"arn:aws:s3:::zappa-*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource": [
"arn:aws:s3:::zappa-*/*"
]
}
]
} |
I am giving Zappa a try and it seems that there are some additional permissions required to use |
For AWS CDK users, here are the settings that worked for me: /** S3 BUCKET FOR ZAPPA LAMBDAS */
const zappaBucket = new s3.Bucket(this, 'ZappaBucket', {
bucketName: `zappa-${this.stackName.toLowerCase()}`,
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
});
/** IAM ROLE FOR ZAPPA LAMBDAS */
const zappaRole = new iam.Role(this, 'ZappaRole', {
assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
description: `Role for Zappa Lambda: ${this.stackName}.`,
roleName: `application-${this.stackName.toLowerCase()}-ZappaLambdaExecutionRole`,
});
const zappaStatement = new iam.PolicyStatement({
actions: ['sts:AssumeRole'],
});
zappaStatement.addServicePrincipal('apigateway.amazonaws.com');
zappaStatement.addServicePrincipal('events.amazonaws.com');
if (zappaRole.assumeRolePolicy) zappaRole.assumeRolePolicy.addStatements(zappaStatement);
// Add Basic Lambda role
zappaRole.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole'));
// S3 Bucket access
zappaBucket.grantReadWrite(zappaRole);
// Add Required Policies for Zappa to run
const zappaBasePolicy = new iam.Policy(this, 'ZappaBasePolicy', {
policyName: 'ZappaBasePolicy',
});
zappaBasePolicy.addStatements(new iam.PolicyStatement({
actions: [
'apigateway:DELETE',
'apigateway:GET',
'apigateway:PATCH',
'apigateway:POST',
'apigateway:PUT',
'events:DeleteRule',
'events:DescribeRule',
'events:ListRules',
'events:ListRuleNamesByTarget',
'events:ListTargetsByRule',
'events:PutRule',
'events:PutTargets',
'events:RemoveTargets',
'lambda:AddPermission',
'lambda:CreateFunction',
'lambda:DeleteFunction',
'lambda:GetAlias',
'lambda:GetFunction',
'lambda:GetFunctionConfiguration',
'lambda:GetPolicy',
'lambda:InvokeFunction',
'lambda:ListVersionsByFunction',
'lambda:RemovePermission',
'lambda:UpdateFunctionCode',
'lambda:UpdateFunctionConfiguration',
'cloudformation:CreateStack',
'cloudformation:DeleteStack',
'cloudformation:DescribeStackResource',
'cloudformation:DescribeStacks',
'cloudformation:ListStackResources',
'cloudformation:UpdateStack',
'logs:DeleteLogGroup',
'logs:DescribeLogStreams',
'logs:FilterLogEvents',
],
resources: ['*'],
}));
zappaRole.attachInlinePolicy(zappaBasePolicy); |
I added
|
To |
Is it worth adding |
I'm getting this to run in CI/CD and just want to run WARNING THIS IS JUST FOR ZAPPA UPDATE, not for deploy
WARNING THIS IS JUST FOR ZAPPA UPDATE, not for deploy |
This repo from Cisco Security has a zappa deployment policy document that is well-written, as well as some explanation of how to use it, an example The actual zappa lambda deployer policy document:
|
For |
I’m looking to kick of a project with Zappa, but per company rules the default policies for AWS access are a bit too lax (allow * is forbidden), so can we get the minimum set of AWS policies to run the example provided?
The text was updated successfully, but these errors were encountered: