Jarkko works as a technical project manager at Gofore and he is a quality and testing oriented professional in the software industry. Depending on the situation, he could be a software engineer or a Scrum Master in addition to being a software tester. Jarkko can also do some DevOps-tasks. Model-based testing and performance testing are his special skills.
This blog series is split into four parts:
- General information of secrets management
- Example how to store secrets into a version control
- Example how to use encrypted secrets in CI-pipelines
- Security issue and threat analysis based on previous examples
After the secrets are stored securely on a version control, it is time to look how a continuous integration pipeline should handle the secrets. In this guide, I’ll use Gitlab’s pipelines.
First of all, you have to create a new service account and a new KMS key which is used only by the service account.
- Head to https://console.cloud.google.com/iam-admin/serviceaccounts, select the project used and create a service account
- Create the private key in JSON format and temporarily store it on your computer. It will be used later when configuring Gitlab CI-pipeline.
- Then open https://console.cloud.google.com/security/kms, select your preferred keyring (or create a new one) and create a new key
- Purpose: Symmetric encrypt/decrypt
- Rotation period: 7 days (I’ll tell about this on the last blog post)
- Select the key created and add the service account with decryption access (‘Cloud KMS CryptoKey Decrypter’) to it
Modifying access to the cryptographic key
Encrypting with a new key
If you have already encrypted secrets, you must add the key to the secrets after setting up the new cryptographic key.
For .sops.yaml configuration, you have to add the new cryptographic key and re-encrypt the secrets. The previous blog post contained the Git pre-commit script which will re-encrypt all secrets if the configuration file is changed.
You can add variables for the CI-pipeline in the project or group settings. I’ll add the following variables to the project settings (Gitlab > Project > Settings > CI/CD > Variables).
|GCLOUD_SERVICE_KEY||<service account key file content in JSON-format)|
Build contains following steps:
- Authenticate and setup gcloud CLI
- Install SOPS
- Decrypt secrets and cache them for the next build steps
- decrypt_secrets.sh -script is the same that was used in the previous blog post.
Gitlab missing features and bugs
- https://gitlab.com/gitlab-org/gitlab-ce/issues/43980 – If you make parallel jobs which stores to cache at same time, it will be incomplete.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/42056 – You can use only one cache, no multiple. Maybe in future, you can cache decrypted secrets to one specific cache.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/59937 – cache: untracked will always store all untracked files to cache. In this case we would like to cache only decrypted secrets, nothing else.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/17850 – There is no regex support for caching specific files.
In the last part of blog series: what vulnerabilities my examples could contain and how to manage them.