Aws-cdk: Default permissions for aws-amplify/App role incorrect

[joekiller]

The role created for the aws-amplify/App by default has insufficient permissions to run. The role needs AdministratorAccess per Adding a Service Role to the Amplify Console When You Connect an App

Reproduction Steps

See the expected test results: integ.app.expected.json

Error Log

My amplify codebuild was throwing errors like:

amplifyPush -e be
(node:1247) UnhandledPromiseRejectionWarning: AccessDenied: Access Denied

Environment

• CLI Version : 1.42.0 (build 3b64241)
• Framework Version:
• Node.js Version:
• OS :
• Language (Version):

Other

My Amplify CodeBuild was throwing errors like AccessDenied because the role was missing.

Thanks for the great tool!

---

This is :bug: Bug Report

[joekiller]

I work around this by applying the permission myself.

amplify_app.grant_principal.add_managed_policy(iam.ManagedPolicy.from_aws_managed_policy_name('AdministratorAccess'))

[MrArnoldPalmer]

@joekiller thanks for pointing this out. I wonder if there is any way to scope this down. Doesn't feel nice to automatically create admin roles for the user. Would like to investigate a bit more.

[jogold]

IAM permissions are only needed when deploying a backend with Amplify. The base case is to deploy a frontend only.

App implements IGrantable. If a user wants to deploy a backend, he should explicitly grant the correct permissions.

[joekiller]

@MrArnoldPalmer I agree it is broad but I'm just the messenger. @jogold the stack is confusingly half setup without the permission and if I recall correctly CDK's opinion is to "do things correctly" versus just the default. Otherwise it wouldn't make IAM roles when you attach CodeCommit. If I wanted half baked Amplify CFN I could've easily written the template myself.

[joekiller]

Call it a no change if y'all want but in hindsight it was confusing to me for a few hours why my builds weren't working when pushing some backend changes as it wasn't clear in many of the docs that the CDK created role was the same as the backend role that needs to be privileged. As soon as I ran builds that do amplifyPush.sh which failed due to permissions it was obvious that my build role was incorrect but to discover the role that was created for CodeCommit access was in fact the same that is used for builds was unclear. Some documentation updates may help. More rtfm?

Fwiw my opinion on amplify is that is is entirely flawed in it's execution as a cloudformation resource anyway because it doesn't properly detect what is inside an existing repo if created by CFN and the role as documented is implied as to only be used for read-only access for CodeCommit.

We do not deploy any amplify configuration via CFN unless amplify is driving it. I have literally used cloudformation for maybe 9 years? Long enough to remember when parallel resource allocation wasn't a thing. So with that said I don't have much of an opinion anymore in this because I will not be using it with amplify. This can just be a tombstone to help others troubleshoot if that's what it comes to.

[MrArnoldPalmer]

@joekiller I agree that this isn't the experience we want, and a documentation update is where we should start.

I've just been spending time reading some amplify issues/comments/docs to see if there is a way for CDK to possibly scope the role to be actually "least needed" in the future. Mostly this which relates to the CLI but maybe gives some hints?

Since the Amplify construct is experimental, I expect there are other issues like this that we need to spend time researching/experimenting with. If it turns out that the only way is to give the service role administrator privileges then I just want that the be clear to the user in docs.

[joekiller]

@MrArnoldPalmer Thanks for the reasonable consideration. I think we all want the best experience for the end user.