Refactor github repository module to use encrypted secret values

[dms1981]

User Story

As a modernisation platform engineer

I want to use encrypted_secret rather than plaintext_secret in the github repository module (terraform/github/modules/repository)

So that secret values are not accidentally exposed

Value

This issue is related to #133 ; this was brought to our attention by a Checkov test while adding details for a new application environment (PPUD). It might be enough to change the attribute reference for aws_secretmanager_version.$name.secret_string to aws_secretmanager_version.$name.secret_binary so that we get a base64 string that will be accepted by github_actions_secret.$name.encrypted_value but in all likelihood it will be more complicated than this.

Questions / Assumptions

• Does CKV_GIT_4 meaningfully apply to this module?
• Are we at risk of inadvertently exposing secret information?
• Is automatic rotation of secrets enough to mitigate any risk from failing?
• Who has access to the state files containing the plaintext values?

Definition of done

• questions have been answered
• code has been refactored so that CKV_GIT_4 passes
• team member has reviewed pull request

Reference

How to write good user stories
CKV_GIT_4

[dms1981]

From some investigation it appears that this Checkov test may not be applicable to the situation where the test fails. There's a very informative comment in the Chekov repository - bridgecrewio/checkov#2374 - that discusses the context for this check.

It appears that while the secret is passed in plaintext when terraform runs, it is not stored in plaintext at rest.
Encrypted values are not stored in terraform state files, but as the state files themselves are controlled and restricted the risk of exposure here is low as only a limited subset of legitimate users have access to those state files.

Finally, scheduled rotation of secrets would be a positive step, but would also require some consideration outside this task.