Amplify-cli: Create IAM user with least privileges
Is your feature request related to a problem? Please describe.
amplify configure creates an IAM user with administrative access as noted in the docs:
By default we give administrator access to this IAM user since the CLI needs access to a variety of services for deployments.
This seems to go against the _principle of least privilege_ outlined by the AWS Well-Architected Framework - Security Pillar (July 2018) whitepaper:
Establishing a principle of least privilege ensures that authenticated identities
are only permitted to perform the most minimal set of functions necessary to
fulfill a specific task, while balancing usability and efficiency.
Describe the solution you'd like
An IAM user with least privilege. In the interim, there should be more guidance on what developers could do to lock down privileges (e.g., example policies).
gitjeff05
All 20 comments
Hello,
Lease privilege is definitely the best practice when using AWS. However, if you also note on page 15 of that document it does recommend CloudFormation as well, which is what the CLI uses to deploy your resources to AWS. The caveat here is that the user invoking CloudFormation creation and updates also requires permissions to interact with what the template has defined:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html
So, technically with the CLI you can define your IAM policy for the role you create (e.g. do not attach and Administrator policy), and attach only the permissions for the services you would be creating with CloudFormation. So for example, the CLI would need permissions to:
- in init, create/update policies in IAM (for your auth/unauth roles)
- Corresponding categories would need permissions for create/update/remove per your use case i.e. if you are using Auth -> Cognito, API/GQL -> AppSync, Analytics -> Pinpoint etc.
So you can least privilege it yourself this way. I agree we should update our documentation for this though and provide the least privilege policy for customers to use if they want, thanks for pointing it out, we are working on updating the docs for this and example policies which I hope to have out this sprint.
mlabieniec
on 25 Oct 2018
This almost sounds like it might be a good candidate for a plugin or extension? The minimal set of privileges could be determined by the amplify/amplify-meta.json correct? So a plugin could:
- Create the policies representing least privilege.
- Add a group backed by those policies.
- Assign the user to that group and drop Administrator (User must be able to switch it back to Administrator)
Or is this typically done with CloudFormation templates andamplify push?
gitjeff05
on 25 Oct 2018
Or maybe a generic security plugin that locked down the privileges for the IAM user among other things (e.g., setup alarms and monitoring). I'm just thinking aloud here...
gitjeff05
on 25 Oct 2018
This is what I have figured out so far:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"appsync:*",

 "apigateway:POST",
"apigateway:DELETE",
"apigateway:PATCH",
"apigateway:PUT",
"cloudformation:CreateStack",
"cloudformation:CreateStackSet",
"cloudformation:DeleteStack",
"cloudformation:DeleteStackSet",
"cloudformation:DescribeStackEvents",
"cloudformation:DescribeStackResource",
"cloudformation:DescribeStackResources",
"cloudformation:DescribeStackSet",
"cloudformation:DescribeStackSetOperation",
"cloudformation:DescribeStacks",
"cloudformation:UpdateStack",
"cloudformation:UpdateStackSet",
"cloudfront:CreateCloudFrontOriginAccessIdentity",
"cloudfront:CreateDistribution",
"cloudfront:DeleteCloudFrontOriginAccessIdentity",
"cloudfront:DeleteDistribution",
"cloudfront:GetCloudFrontOriginAccessIdentity",
"cloudfront:GetCloudFrontOriginAccessIdentityConfig",
"cloudfront:GetDistribution",
"cloudfront:GetDistributionConfig",
"cloudfront:TagResource",
"cloudfront:UntagResource",
"cloudfront:UpdateCloudFrontOriginAccessIdentity",
"cloudfront:UpdateDistribution",
"cognito-identity:CreateIdentityPool",
"cognito-identity:DeleteIdentityPool",
"cognito-identity:DescribeIdentity",
"cognito-identity:DescribeIdentityPool",
"cognito-identity:SetIdentityPoolRoles",
"cognito-identity:UpdateIdentityPool",
"cognito-idp:CreateUserPool",
"cognito-idp:CreateUserPoolClient",
"cognito-idp:DeleteUserPool",
"cognito-idp:DeleteUserPoolClient",
"cognito-idp:DescribeUserPool",
"cognito-idp:UpdateUserPool",
"cognito-idp:UpdateUserPoolClient",
"dynamodb:CreateTable",
"dynamodb:DeleteItem",
"dynamodb:DeleteTable",
"dynamodb:DescribeTable",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:UpdateTable",
"iam:CreateRole",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:GetRole",
"iam:GetUser",
"iam:PassRole",
"iam:PutRolePolicy",
"iam:UpdateRole",
"lambda:AddPermission",
"lambda:CreateFunction",
"lambda:DeleteFunction",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:InvokeAsync",
"lambda:InvokeFunction",
"lambda:RemovePermission",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"s3:*"
],
"Resource": "*"
}
]
}
( appsync:* ) to maintain my sanity...
( s3:* ) as the _storage_ is failing with "Access Denied" when creates bucket, even when I have appropriate rights...
Please note, we do not use _notifications_, so it was out of my scope. If you could update this list it would be great.
plague-doctor
on 17 Jan 2019
Hello,
Lease privilege is definitely the best practice when using AWS. However, if you also note on page 15 of that document it does recommend CloudFormation as well, which is what the CLI uses to deploy your resources to AWS. The caveat here is that the user invoking CloudFormation creation and updates also requires permissions to interact with what the template has defined:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.htmlSo, technically with the CLI you can define your IAM policy for the role you create (e.g. do not attach and Administrator policy), and attach only the permissions for the services you would be creating with CloudFormation. So for example, the CLI would need permissions to:
- in init, create/update policies in IAM (for your auth/unauth roles)
- Corresponding categories would need permissions for create/update/remove per your use case i.e. if you are using Auth -> Cognito, API/GQL -> AppSync, Analytics -> Pinpoint etc.
So you can least privilege it yourself this way. I agree we should update our documentation for this though and provide the least privilege policy for customers to use if they want, thanks for pointing it out, we are working on updating the docs for this and example policies which I hope to have out this sprint.
I may be mistaken, but I believe the OP was not referring to the permissions that are defined by the CloudFormation. I believe he is referring to the permissions given to the user running amplify from the CLI.
I have a similar concern in that we want to allow a small set of user accounts the ability to run amplify, and we'd like to do it in a least-privilege fashion.
matthewbga
on 9 Jul 2019
EDIT. I mistakenly thought this was case closed - my apologies.
While creating an admin user via amplify init is ok in a sandbox-type environment with a small team, it's very problematic in scenarios where trying to use e.g. amplify add codegen against a stable AppSync API in a secure environment written by another (backend) team, as is common in larger projects.
At the very least, Amplify should document what the actual least privs are.
jkodroff
on 24 Jul 2019
@jkodroff We have a section out here documented for this - https://aws-amplify.github.io/docs/cli-toolchain/usage#iam-policy-for-the-cli
The policies which you would choose from the above documentation would be
very specific to your use-case and you can eliminate the one's or select the one's which you need/don't need.
kaustavghosh06
on 24 Jul 2019
That list seems to be missing permissions for things like pubsub, push notifications, predictions, etc. Is there a more exhaustive list available?
mayteio
on 28 Aug 2019
Bumping this. Our typical AWS administrator is not managing amplify setup, so we have to create an IAM user for the person that is. It would be great to have an updated list with the additional permissions listed above.
atlowell-smpl
on 14 Jan 2020
When trying to paste the JSON above to create a policy I receive this error, is there a way around that?
ajonp
on 17 Jan 2020
Just to follow up, when I remove the API Gateway and seperate that into a seperate policy, creating two policies instead of all inline. This gets the character size down to the required size.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"appsync:*",
"cloudformation:CreateStack",
"cloudformation:CreateStackSet",
"cloudformation:DeleteStack",
"cloudformation:DeleteStackSet",
"cloudformation:DescribeStackEvents",
"cloudformation:DescribeStackResource",
"cloudformation:DescribeStackResources",
"cloudformation:DescribeStackSet",
"cloudformation:DescribeStackSetOperation",
"cloudformation:DescribeStacks",
"cloudformation:UpdateStack",
"cloudformation:UpdateStackSet",
"cloudfront:CreateCloudFrontOriginAccessIdentity",
"cloudfront:CreateDistribution",
"cloudfront:DeleteCloudFrontOriginAccessIdentity",
"cloudfront:DeleteDistribution",
"cloudfront:GetCloudFrontOriginAccessIdentity",
"cloudfront:GetCloudFrontOriginAccessIdentityConfig",
"cloudfront:GetDistribution",
"cloudfront:GetDistributionConfig",
"cloudfront:TagResource",
"cloudfront:UntagResource",
"cloudfront:UpdateCloudFrontOriginAccessIdentity",
"cloudfront:UpdateDistribution",
"cognito-identity:CreateIdentityPool",
"cognito-identity:DeleteIdentityPool",
"cognito-identity:DescribeIdentity",
"cognito-identity:DescribeIdentityPool",
"cognito-identity:SetIdentityPoolRoles",
"cognito-identity:UpdateIdentityPool",
"cognito-idp:CreateUserPool",
"cognito-idp:CreateUserPoolClient",
"cognito-idp:DeleteUserPool",
"cognito-idp:DeleteUserPoolClient",
"cognito-idp:DescribeUserPool",
"cognito-idp:UpdateUserPool",
"cognito-idp:UpdateUserPoolClient",
"dynamodb:CreateTable",
"dynamodb:DeleteItem",
"dynamodb:DeleteTable",
"dynamodb:DescribeTable",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:UpdateTable",
"iam:CreateRole",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:GetRole",
"iam:GetUser",
"iam:PassRole",
"iam:PutRolePolicy",
"iam:UpdateRole",
"lambda:AddPermission",
"lambda:CreateFunction",
"lambda:DeleteFunction",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:InvokeAsync",
"lambda:InvokeFunction",
"lambda:RemovePermission",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"s3:*"
],
"Resource": "*"
}
]
}
@ajonp it looks from your error that the issue is with the user, not the policy length. I'm assuming you're editing a policy that is already added to the user? I was able to create the JSON policy in that document, so you may need to remove other policies from the user to get it to work.
atlowell-smpl
on 17 Jan 2020
Also a followup to above: when using the list of permissions specified in the linked amplify documentation, we encountered an issue where our cli was missing access to cognito-idp:ListTagsForResource. Unsure of whether that is specific to our project or a general policy needed that is missing from the documented list.
atlowell-smpl
on 17 Jan 2020
Right now we are unable to get past this
AccessDeniedException: User: arn:aws:iam::728254918237:user/compass-amplify2 is not authorized to perform: amplify:CreateApp on resource: arn:aws:amplify:us-east-2:728254918237:apps/*
Seems to be missing an additional resource, but I have no idea for what role. If this is separate I can open a new issue, but we are trying to find the minimal amount of policy as well.
ajonp
on 17 Jan 2020
Right now we are unable to get past this
AccessDeniedException: User: arn:aws:iam::728254918237:user/compass-amplify2 is not authorized to perform: amplify:CreateApp on resource: arn:aws:amplify:us-east-2:728254918237:apps/*Seems to be missing an additional resource, but I have no idea for what role. If this is separate I can open a new issue, but we are trying to find the minimal amount of policy as well.
You need to give amplify:* as one of the permissions in the policy. You can find a more official list in the amplify docs link commented by @kaustavghosh06 above, but as mentioned by me and others it seems to be missing some cases.
atlowell-smpl
on 17 Jan 2020
To add to this, assuming you are able to get a least-privileged IAM user for use with the Amplify CLI, you will hit another roadblock when attempting to configure the build settings for your Amplify app. If you want to deploy the backend of your app when your repo is updated, you'll need to create a service role for Amplify that has Administrator Access: https://docs.aws.amazon.com/amplify/latest/userguide/how-to-service-role-amplify-console.html
hous
on 6 Feb 2020
I found this issue and the docs at https://docs.amplify.aws/cli/usage/iam.
We want to allow developers to use the amplify cli in a least-privileged manner as discussed above for dev and test environments + be able to create their own sandboxes. We want to explicitly deny access to the production environments.
Has anyone attempted this. My initial approach was an AmplifyCLI group and a DenyProduction group. Is that a reasonable approach?
rpinna
on 23 Apr 2020
The documentation at https://docs.amplify.aws/cli/usage/iam contains the set of privileges needed for Amplify CLI to perform correctly across all categories. For larger teams it could be created as a Managed Policy which has a size limit of 6Kb and then attach that Managed Policy straight to a IAM User or create a single Role that is assigned to the Users directly, that way that is an decoupling provided which can be scaled for various team sizes with less management overhead. If you find a missing permission in the above stated policy feel free to open a new issue about that.
attilah
on 20 May 2020
How to give particular instance types with amplify
manneharikrishna
on 23 Jul 2020
creating a User with administrative access is very dangerous. My client account got Un-Authorized access due to this and his account got suspended we wasted 4 to 5 days figuring out and fixing it.
I would recommend to change the Default IAM user permission to as minimum as possible.
bhaveshdaswani93
on 22 Oct 2020
Related issues
gabriel-wilkes
·
3Comments
zjullion
·
3Comments
ReidWeb
·
3Comments
jeanpaulcozzatti
·
3Comments
nason
·
3Comments
Most helpful comment
This is what I have figured out so far:
( appsync:* ) to maintain my sanity...
( s3:* ) as the _storage_ is failing with "Access Denied" when creates bucket, even when I have appropriate rights...
Please note, we do not use _notifications_, so it was out of my scope. If you could update this list it would be great.