Usual problem with software development, since I started working, is handling configuration and keeping secrets. For managing secrets I have tried AWS secret manager and Google secret manager. I even tried keeping configuration in "plain sight", but encrypted using SOPS. I learned this approach from my colleague and I think it would be useful I share it here.

SOPS is a tool for encrypting and decrypting configuration files so they can be safely stored in version control. It is not a secret manager, but it can be used to manage secrets when combined with an external key authority.
SOPS integrates with key management services, and decryption is only possible for identities that have access to the configured keys.
For a full list of supported KMS backends, see the documentation. In this setup, I used Google Cloud KMS.

Enable Google Cloud KMS

Go to google console cloud apis and services, and enable Cloud Key Management Service API (cloudkms.googleapis.com)

Authenticate

gcloud auth login
gcloud auth application-default login

Second line creates application default credentials for libraries like SOPS.

Other option is to create a service account with encrypter/decrypter role. Download the service account json and point to GOOGLE_APPLICATION_CREDENTIALS environment variable.

Create a keyring

gcloud kms keyrings create <keyring_name> --location=global --project=<your_project_id>

Create a key in that keyring

gcloud kms keys create <key_name> --location=global \
--keyring=<keyring_name> --purpose=encryption --project=<your_project_id>

Encrypt


sops --encrypt
--gcp-kms projects/<your_project_id>/locations/global/keyRings/<keyring_name>/cryptoKeys/<key_name> .env.prod > sops.env.prod

Edit the file and save. For updating configuration, just open you file with `sops .env.prod`, edit, save and commit to versioning, so other colleagues can pull it.

Granting decrypt permissions

Only the accounts that have the role of Cloud KMS CryptoKey Decrypter can decrypt the file. Remember this when you need to add a new team member, I mean IAM role. Same rule applies for GitHub actions. If decrypting the file is crucial for running your GitHub action, you would create a new service account with decrypter role, and assign it to GOOGLE_APPLICATION_CREDENTIALS GitHub environment variable.

Benefit of this approach is git becomes source of truth for managing configuration, without exposing what the configuration is. It's bad for frequently rotated config values, because it needs to go through the usual PRs and multi stage branch merging (if you have something like dev->staging->production).

Youtube: https://youtu.be/tP2h-2pb4p4

#Security #GitHub #GCP