Skip to content
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

Publish AwsCommunity::IAM::PasswordPolicy #264

Open
2 tasks
benbridts opened this issue May 6, 2024 · 3 comments
Open
2 tasks

Publish AwsCommunity::IAM::PasswordPolicy #264

benbridts opened this issue May 6, 2024 · 3 comments

Comments

@benbridts
Copy link
Contributor

What type of extension are you looking for?

Resource

Describe the extension you'd like to request

AwsCommunity::IAM::PasswordPolicy exists in source code form, it would be great if I could activate it in my account without having to build/publish it myself.

Describe the solution you'd like

AwsCommunity::IAM::PasswordPolicy being available as a Third Party Public Extension

Additional context

No response

Is this something that you'd be interested in working on?

  • 👋 I may be able to implement this feature request

Would this feature include a breaking change?

  • ⚠️ This feature might incur a breaking change
@ericzbeard
Copy link
Contributor

We can't publish anything that needs IAM permissions other than PassRole.

@benbridts
Copy link
Contributor Author

benbridts commented May 7, 2024

That's an annoying restriction.

The workaround for that is to:

  • add a property "InvokeRoleArn"
  • do an assumeRole in the handler to get a session in that role, (should be possible because sts:assumeRole is not an iam action
  • If that role has the right permissions, this should just work.

It's annoying to do that, and the security win of blocking iam is roughly 0; needing the consumer to not put iam:* in the role that's attached during the activation, or needing them to not add it to the role that is passed as a property, leaves the same responsibility for the user.

That being said,
It would be nice if that was gated behind CAPABILITY_IAM both during activation and stack deployment.


Edit:
Is there any interest in accepting the hacky-workaround as a code change, or do we want to give a good example here?

@ericzbeard
Copy link
Contributor

I think we should leave the example as it is for now. I'll bring up the possibility of removing the restriction again internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants