feat(iam): generate AccessKeys#18180
Conversation
|
|
84a9543 to
0a16ca3
Compare
This adds an L2 resource for creating IAM access keys. Instructions for creating access keys are added to the README near the information on creating users. Tests are added (including an integration test) and locations elsewhere in the CDK where `CfnAccessKey` was used have been updated to leverage the new L2 construct (which required changes in the `secretsmanager` and `apigatewayv2-authorizers` packages). Excludes were added for two `awslint` rules. Access Keys don't support specifying physical names, so having such a property is impossible. Additionally, since the primary value of an `AWS::IAM::AccessKey` is to gain access to the `SecretAccessKey` value, a `fromXXX` static method doesn't seem to make a lot of sense (because ideally you'd just pull that from a Secret anyway if it was required in the app).
0a16ca3 to
a4afd62
Compare
|
Thanks for this! I'm all good with it, except I do have a slight concern about the Hold on while we discuss internally. |
|
Thanks! I looked into using It's a little unfortunate that with the L1 construct it was being output and that there aren't more protections at the CloudFormation level to discourage that, but it'd be awesome to at least provide that safety at a higher level in the CDK codebase. Looking forward to seeing what those internal discussions yield and how this construct can be safer! |
|
Yes I think wrapping it in a |
This doesn't achieve a lot by itself just yet, but it will if we change `SecretValue` a little.
`toString()` needs to be called on the `SecretValue` because it requires a string argument. And the same needs to be done in with JSON, otherwise the `toJSON` in `Intrinsic` seems to be used and that does not result in a token being returned.
It seems `.toString()` needs to be called on `SecretValue`s being `JSON.stringify`-ed.
This adds the new required call to `.toString()` to retrieve the value.
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This adds an L2 resource for creating IAM access keys. Instructions for creating access keys are added to the README near the information on creating users. Tests are added (including an integration test) and locations elsewhere in the CDK where `CfnAccessKey` was used have been updated to leverage the new L2 construct (which required changes in the `secretsmanager` and `apigatewayv2-authorizers` packages). Excludes were added for two `awslint` rules. Access Keys don't support specifying physical names, so having such a property is impossible. Additionally, since the primary value of an `AWS::IAM::AccessKey` is to gain access to the `SecretAccessKey` value, a `fromXXX` static method doesn't seem to make a lot of sense (because ideally you'd just pull that from a Secret anyway if it was required in the app). I looked into integrating with `secretsmanager.Secret` as part of this PR; however, at this time it's currently experimental to support strings via tokens and the experimental resource's documentation isn't available so it seemed suboptimal to do that integration. Resolves: aws#8432 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This adds an L2 resource for creating IAM access keys. Instructions for
creating access keys are added to the README near the information on
creating users. Tests are added (including an integration test) and
locations elsewhere in the CDK where
CfnAccessKeywas used have beenupdated to leverage the new L2 construct (which required changes in the
secretsmanagerandapigatewayv2-authorizerspackages).Excludes were added for two
awslintrules. Access Keys don't supportspecifying physical names, so having such a property is impossible.
Additionally, since the primary value of an
AWS::IAM::AccessKeyis togain access to the
SecretAccessKeyvalue, afromXXXstatic methoddoesn't seem to make a lot of sense (because ideally you'd just pull that
from a Secret anyway if it was required in the app).
I looked into integrating with
secretsmanager.Secretas part of this PR;however, at this time it's currently experimental to support strings via
tokens and the experimental resource's documentation isn't available so it
seemed suboptimal to do that integration.
Resolves: #8432
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license