Best practices for managing secrets

[pbobov]

The workflows use GitHub Actions secrets to store credentials of user identities not created by the workflows, such as AWS keys and ArcGIS Online credentials, and use config files in the repository for all other sensitive configuration data. Storing unencrypted secrets in GitHub repositories is not a best practice even if the repository is private.

Use Secret Managers to Store ALL the Secrets

To mitigate the risk the workflows could be modified to store the secrets in GitHub Actions secrets or other secret managers like HashiCorp Vault, AWS Parameter Store, or AWS Secret Manager.

For example, a password could be stored in GitHub Actions secret "PASSWORD", read into an environment variable by the workflow PASSWORD: ${{ secrets.PASSWORD }}, and passed to the terraform module by setting an input variable in the command line parameters -var=password=$PASSWORD.

Passing secrets in command line parameters is also not a good practice, but the risk could be mitigated by making sure that the secrets are not leaked into the shell output.

Another drawback of this approach is that it separates management of secrets from other configuration data. In particular, that makes it harder to manage failover deployments as each deployment requires its own group or secrets addressed by unique secret names. For example, there may be multiple deployments in the repository that use the same template, and the workflows need to be modified for each deployment to use different secrets. That does not pair well with the gitops methodology.

Environmental secrets could be used to make secrets available to workflow jobs that reference the environment.

The configuration files may use secret names instead of the secrets values.

Encrypt Secrets in the Config Files

Another approach is to encrypt secrets in the config files using tools like SOPS.

For example, the workflows could install SOPS on GitHub Actions runners and decrypt the config files using AWS KMS keys defined in a GitHub Actions secret.

This approach looks attractive from the security perspective, but it complicates the configuration management because the config files in the repository must be encrypted by SOPS before they are committed. In particular, it’s not clear how to use SOPS on Windows machines.