Option to disable auto-generated policies when using @auth with IAM provider

[ghost]

Is your feature request related to a problem? Please describe.

I would like to re-address the issue mentioned here: aws-amplify/amplify-cli#2776

When in a project that includes an identity pool, the policy for the auth/unath roles automatically includes permissions for every added "@auth" with "provider: iam".
This is a problem if some fields are meant to be updated only by e.g. a lambda function.

What we want to achieve is exactly the same as what is mentioned in the last example from: https://docs.amplify.aws/cli/graphql-transformer/directives#combining-multiple-authorization-types which states that:

"In the following example the model is protected by Cognito User Pools by default and anyone with a valid JWT token can perform any operation on the Post type, but cannot update the secret field. The secret field can only be modified through the configured IAM policies, from a Lambda function for example."

type Post @model @auth (rules: [{ allow: private }]) {
  id: ID!
  title: String
  owner: String
  secret: String
    @auth (rules: [{ allow: private, provider: iam, operations: [create, update] }])
}
}

When an identity pool is used (which I believe it is in the default configuration for auth - correct me if I'm wrong) this isn't possible, and in fact the above mentioned schema grants every authenticated user the same permissions as they would have had, even if the auth directive wasn't added to the secret field at all.

I'm aware that this behaviour is mentioned briefly at: https://docs.amplify.aws/cli/graphql-transformer/directives#private-authorization, but I believe that the wording in the example above is very misleading, and that we need some way to turn off the auto-generated IAM polices.

Describe the solution you'd like
Some way to add @aws_iam to types in the generated schema, without automatically adding permissions to the auth role.

Without knowing anything about the workings of the amplify cli, I imagine this could be done by adding "lambda", "customIAM" or something similiar to the AuthStrategy enum in the @auth directive. Using this authstrategy would add @aws_iam to the schema, without auto-generating permissions.

Describe alternatives you've considered
Another solution might be to add a toggle when adding IAM as an auth type for the api, asking if permissions should automatically be added to the auth/unath roles.

Additional context
The only workaround that I've been able to find, is adding all users to a generic group, so that they aren't assigned the default auth role. This doesn't seem like a solution though, given that:

• Assigning a user to a user group to de-escalate privilege seems counter-intuitive.
• If the postConfirmation trigger that assigns each user to a group for some reason fails, the user if left with full IAM permissions
• Theoretically there's a small delay between confirming a user, and being added to a group. I don't know if this poses a real security issue, but this could potentially be abused.

Let me know if I am missing something obvious here, or if there's already an open issue regarding this.

[akshbhu]

I have added this to our backlog for prioritization, once this is prioritized we will work on this. Feel free to 👍 so this gets more visibility

[ghost]

I have added this to our backlog for prioritization, once this is prioritized we will work on this. Feel free to 👍 so this gets more visibility

If we can agree on a solution, I might be able to spent a bit of time on this. For our team, it would be sufficient to be able to simply turn off the policy generation, leaving us to handle it manually. This is also most likely the simplest way to add this feature.

What's your take on this?

[ghost]

Having had a look behind the scenes, we will try adding a checkbox inquiry for policy generation when adding IAM as an auth type for the api. This allows us to toggle the auth and/or the unauth role.

If this turns out to be a viable solution for us, you can determine if this is also a viable solution for "the general user" and if so, we will create a pull request.

[blazinaj]

Bump. This is huge for us. We have been fighting with the IAM Limit of 'Cannot add more than 20 policies to the Role' because we have too many schema models with IAM configured so that we can use Lambda functions.

What makes this worse is that it looks like we don't even need these policies for the Lambdas, as they are only being generated so that the frontend role can access data using IAM (which we don't even want!)

We have effectively reached the maximum amount of @models that we can have in our Amplify project, and can no longer proceed with development, all because these auto generated policies are killing the build pipeline when it tries to generate the 21st policy for the role.

The IAM and Amplify teams have just told us 'just change your schema to make it smaller' which is not a solution at all for a production application.

Since this issue is 2 years old, it's obvious this may not get fixed any time soon. Does anyone have any suggestions for hacking the CLI tool to prevent it from trying to create these policies?