feat(iam): generate AccessKeys

[laurelmay]

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: #8432

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[rix0rrr]

Thanks for this!

I'm all good with it, except I do have a slight concern about the accessKey.secretAccessKey attribute. The use as demonstrated in the integ test (sticking the value directly into a CfnOutput) is unsafe, and we should see if there's a way we can programmatically discourage that.

Hold on while we discuss internally.

[laurelmay]

Thanks! I looked into using SecretValue.plainText but that doesn't seem to be used directly throughout the library (outside of tests). It also doesn't really prevent outputting the value (though it does require an extra .toString() call). Maybe that at least gets the point across a little better?

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!

[rix0rrr]

Yes I think wrapping it in a SecretValue might do the job--though we have to review SecretValue and its API. Unfortunately a toString() is not a good enough barrier. That might accidentally get called implicitly. I'd prefer an explicit method like value.unsafeUnwrap() or something.

Pull request has been modified.

Pull request has been modified.

[mergify]

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-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 9874f21
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

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).