You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 11, 2023. It is now read-only.
name: Pull request template
about: Make a PR to terraform-aws-foundation
Please include the following in your PR:
Please also note that these are not hard requirements, but merely serve to define
what maintainers are looking for in PR's. Including these will more likely lead
to your PR being reviewed and accepted.
Update the changelog
Make sure that modules and files are documented. This can be done inside the module and files.
Make sure that new modules directories contain a basic README.md file.
Make sure that there is an up to date example for your code:
- For new modules this would entail example code for how to use the module or some explanation in the module readme.
- For new examples please provide a README explaining how to run the example. It's also ideal to provide a basic makefile to use the example as well.
Make sure that there is a manual CI trigger that can test the deployment.
@ketzacoatl On further thought, I think we should remove the entire vault-aws-backend module itself from terraform (because we don't want admin secret in Terraform's state file and just having vault_aws_secret_backend_role resource isn't useful).
Also, I don't think it is useful for us to make vault-s3-private use vault-iam module, because they are not dependent. Only the running vault server's secret engine needs the access keys from the vault-iam module. No other output from vault-iam is actually needed for it in vault-s3-private. I think the right way for us to proceed would be:
Have make target step for the vault-iam module. This step will create access keys which has to exposed via environment variables by us manully for the next step.
Have another make target step (like what you have suggested) to create AWS secret engine path and create an appropriate role for this. (This step will completely replace the vault-aws-backend module). This step will require proper environment variable for access keys to be present for it to work.
I would comment though, that if there are no secrets, and we can do it in Terraform, we ought to. Some of the vault configuration can be done in Terraform and doesn't include secrets. Those should stay in Terraform. IDK if that is relevant to the vault-aws-backend module, I haven't reviewed the code in a few days.
@psibi are these updates WIP or is it ok to have one of our engineers make those updates?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
name: Pull request template
about: Make a PR to terraform-aws-foundation
Please include the following in your PR:
Please also note that these are not hard requirements, but merely serve to define
what maintainers are looking for in PR's. Including these will more likely lead
to your PR being reviewed and accepted.
- For new
modulesthis would entail example code for how to use the module or some explanation in the module readme.- For new examples please provide a README explaining how to run the example. It's also ideal to provide a basic makefile to use the example as well.