Explain the opinions that have been implemented in CFT
hab25 opened this issue · 1 comments
TL;DR
Explain the opinions that have been implemented in CFT.
Terraform Resources
No response
Detailed design
Add comments explaining opinions/decisions in the module's *.tf files. Mention that one can refer to those comments in the upfront documentation.Additional information
This is generally about CFT, and not specific to terraform-google-modules. Please let me know if there is a better place for this issue.
CFT is great. It allows me to quickly, and in an opinionated manner, set up my infrastructure. Also the opinions come from people who are probably better than me at this problem, and probably have spent longer thinking about it than I have or am willing to.
But, it isn't perfect, and sometimes one should diverge from it. Therefore, understanding why CFT has a certain opinion is very important to the user and their experience, so that they can better use it and more correctly diverge from it as needed.
Google seems to generally agree with this as their products generally come with very strong documentation. CFT does not seem to be following suit, though.
An anecdote where documentation could have greatly helped: I was interested in using this repo's cloudbuild submodule. Reading https://github.com/terraform-google-modules/terraform-google-bootstrap/tree/v4.2.0/modules/cloudbuild#readme, I saw that KMS was being created and had no documented option to disable it. I did not understand this and thought:
- Why is KMS creation not only default but has no input to disable it? This is a bootstrapping module. Is it really so ubiquitous that everyone should encrypt things generally early in infrastructure development? If so, this and this say nothing of encryption.
- What am I supposed to be encrypting? Considering the fact that Secret Manager wasn't chosen instead of KMS, and #78, I guessed that the intention was to encrypt terraform state. There's GCS object-level IAM for that. Why would KMS be better? Given that KMS would probably also be secured through IAM, it seems like the outcome is the same attack surface, but with more complexity.
- The reason given in #78's OP, which sites cases where 'IAM is not well-restricted', doesn't seem appropriate either, as that is diverging from best practices which to my understanding is what CFT targets.
I then saw #143 and guessed that the maintainers came to the same conclusion. And I emphasize guessed because the documentation on the change is also lacking in explanation (why was it removed?).
PS: This might have been too long or unfocused. I don't have much experience contributing to open source and am not sure how much and what details are appropriate, so any feedback in this regard is welcome.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days