Is your feature request related to a problem? Please describe.
I'm always frustrated when I can't use Amplify as whenever the IAM Roles try to get created in our AWS environment, due to the fact there is no IAM Permission Boundary applied to the roles, the IAM Roles fail to create 馃槩 . This means we can't use Amplify CLI to pre-create the AWS Resources.
Describe the solution you'd like
Whenever I use the AWS Amplify CLI to initialise a project, I would like to be able to pass in custom IAM Elements to be applied to the roles that get created. I could see this being done in a few ways.
--iam-attributes
) and this flag accepts a yml file (something like iam-roles-custom-attributes.yml
) where I am able to pass in my custom IAM key/value stores (cloud formation). I think it should still use the default IAM Role(s) which get created by the Amplify CLI, I just need to be able to pass in custom values, that either override or append onto the custom roles that get created. If that makes sense?Describe alternatives you've considered
--custom-attributes
which takes a valid cloud formation yml file which uses the values in that file to append onto the resources being created by Amplify.I have been thinking of a good way of doing this, and I really can't think of a great option 馃槩 I am very open to suggestions on how this can be found, I think passing in a cloud formation file with attributes (which in my case is the IAM Boundary) which appends onto the roles that are native created by Amplify.
Additional context
I don't think there is too much more context to share, in our environment, any IAM Roles that get created need to have a permission boundary applied, otherwise there is a policy that doesn't allow the roles to be created. We really would like to use the Amplify CLI, but due to our permission boundary, it isn't allowed 馃槩.
If this issue isn't clear (sorry) I am happy to explain a little more 馃憤
Transferring from JS, as this appears to be CLI-related.
@NickLiffen this is a hard area, to be generalized as you also found it out, since the CLI do require a set of permissions to be able to work correctly without problems. I think that beside that you'd like to have some solution for advanced use cases where the environment or the requirements are different than usual.
Do you think that it is only needs to be done for the init flow, because we also create and assign IAM permissions when creating/updating resources during deployment?
Hey 馃憢 I completely agree this is a hard area 馃槩 the value of the Amplify CLI is it wraps an opinionated layer around AWS Services to meet a common use case; and what I am asking for, although I believe can be seen as a pattern, I understand is slightly "off pattern" from the standard use case.
If we thought IAM Boundaries was a common pattern it would be great if you could even pass in a flag directly to the CLI Command --iam-permissionsBoundary
and we would pass in the Arn value. But I have a feeling this is too specific and would only meet a one off use case.
Maybe it's something we could add to the config.json
file? 馃 馃挱 This could be better then passing in something to the CLI directly?
Do you think that it is only needs to be done for the init flow, because we also create and assign IAM permissions when creating/updating resources during deployment?
This is a great point! Yes, it would need to really be applied to any stack CRUD action, like creation, updating, etc. Anything in Amplify that touches the IAM Roles, would need this applied.
I am more than happy to contribute and help with this work, but I just wanted to align if this was coming you would be willing to accept into the Amplify framework. It would be amazing to help us use Amplify in our enterprise environment. 馃憤
Thanks for your response to this 馃挴
@brene or @attilah any thoughts? 馃 馃挱 sorry to push, just curious to see your thoughts.
This was asked for a while ago but there has been little movement on that issue #1311
I would be happy with an interim solution where I manually create the required roles and then during init I am prompted "Do you want to use existing roles or create new?"
So for the amplify init
flow I would create the UnAuth and Auth roles upfront and then specify those.
This would make the init flow more complicated but I'd hide these prompts behind a flag so if a user needs these they could do something like amplify init --advanced
Most helpful comment
This was asked for a while ago but there has been little movement on that issue #1311
I would be happy with an interim solution where I manually create the required roles and then during init I am prompted "Do you want to use existing roles or create new?"
So for the
amplify init
flow I would create the UnAuth and Auth roles upfront and then specify those.This would make the init flow more complicated but I'd hide these prompts behind a flag so if a user needs these they could do something like
amplify init --advanced