v1.0.0 (Breaking changes)

Remove expiring keys and awsutils provider, fix bugs @Nuru (#70)

note

Starting with version 0.23.0 of this module, AWS Access Keys created by this module expired in 30 days by default. This release removes the ability to create expiring keys, and non-expiring keys are created by default. This release also defaults to storing the keys in AWS SSM Parameter store and not passing them as outputs, because the outputs are stored unencrypted in the Terraform state file.

We recommend authenticating via an OIDC provider rather than using AWS Access Keys.

what

• Remove iam_access_key_max_age and the ability to create AWS Access Keys of predefined lifetime
• Output secrets only when not using SSM Parameter Store
• Enhance testing

why

• We are removing this feature due to the confusion to the community of our terraform users that has been caused by requiring the cloudposse/awsutils Terraform provider to provide the feature. The error messages stemming from the missing provider block configuration are causing more of a support headache than it is worth. Since we implemented this feature, most CI/CD providers have implemented a better way to obtain short-lived CI/CD credentials (e.g. GitHub Actions and CircleCI both support OIDC with AWS, GCP, Azure, etc)
• Secrets that are output from a module, even if marked sensitive, are still stored in plaintext in the Terraform state file, which makes them less secure than AWS Parameter Store.
• Prevent regression of fixed bugs

references

• Closes #54
• Closes #62
• Closes #67
• Supersedes and closes #68

feat: add ses smpt password to ssm, add ssm base path option @Gowiem (#65)

what

• Add option to change the SSM base path under which credentials are stored
• Store ses_smtp_password_v4 in SSM

why

• Even if the IAM users are global per account often times there is a need to separeate them per environment (dev, staging). By adding the ssm_base_path parameter we can have a better SSM hierarchy. Example: /dev/system_user/tc-dev-s3 and /staging/system_user/tc-staging-ses
• Also having the ses_smtp_password_v4 stored in SSM will allow better integration with CI systems when deploying applications (rather than having a script to generate the password or read the terraform state)

references

• Link to any supporting github issues or helpful documentation to add some context (e.g. stackoverflow).
• closes #60
• Copy of #61, Closes #61

git.io->cloudposse.tools update @dylanbannon (#64)

what and why

Change all references to git.io/build-harness into cloudposse.tools/build-harness, since git.io redirects will stop working on April 29th, 2022.

References

• DEV-143