3 ms·

If I'd decide to keep the secrets in the repo, I would have them encrypted with e.g. GnuPG and put a key in the CI's environment variables. # Something in

If I'd decide to keep the secrets in the repo, I would have them encrypted with e.g. GnuPG and put a key in the CI's environment variables. # Something in lines of this... # TODO: Make sure the keyrings are on tmpfs, too. # Something like export GNUPGHOME="/run/gnupg" && mkdir -p "$GNUPGHOME" gpg2 -v --import <(echo "$GPG_PRIVATE_KEY") gpg2 --decrypt --output /run/secrets/credentials.json lib/credentials.json.gpg ln -s /run/secrets/credentials.json lib/credentials.json For this I have to trust the CI, of course... And given that CI jobs run in isolated environments but on a shared hosts, there could be a way for malicious party to access the data. IIRC, there were some exploits that break out of Docker. If you host in the cloud that offers a KMS (AWS, GCP, Azure), a slightly advanced alternative is SOPS: https://github.com/mozilla/sops https://github.com/mozilla/sops (you can use that with GnuPG as well)

iancarroll 8y ago
I don’t get what this accomplishes. You can either put the secrets in the environment variables, or put all the information required to decrypt the environment variables in the environment variables. What does the latter give you?
- drdaeman 8y ago
  Idea is, if someone gets access to your CI environment but not the repo - they don't have the data to decrypt. E.g. if your CircleCI password is leaked, but GitHub is safe. In my experience, most CI websites don't allow to browse the source code. That's not ideal - IIRC, CircleCI in particular has a feature to run the build with SSH, so a sufficiently aware attacker still has a way to get the decrypted data. Still, an extra obstacle. Just that security's not binary. Also, this way you can manage the secrets in your repo. No need to log in to CI and use their web UI to edit the passwords. I think that's convenient. Sops is a better idea, because you can't extract keys from the KMS.
  - jwhitlark 8y ago
    This problem is one reason why it's important to separate CI from CD. If you do that, then circleci would only have what's needed to test and package it, and the CD can handle the rest, although ideally you'll have a third piece for secrets.

iancarroll 8y ago

I don’t get what this accomplishes. You can either put the secrets in the environment variables, or put all the information required to decrypt the environment variables in the environment variables. What does the latter give you?

drdaeman 8y ago
Idea is, if someone gets access to your CI environment but not the repo - they don't have the data to decrypt. E.g. if your CircleCI password is leaked, but GitHub is safe. In my experience, most CI websites don't allow to browse the source code. That's not ideal - IIRC, CircleCI in particular has a feature to run the build with SSH, so a sufficiently aware attacker still has a way to get the decrypted data. Still, an extra obstacle. Just that security's not binary. Also, this way you can manage the secrets in your repo. No need to log in to CI and use their web UI to edit the passwords. I think that's convenient. Sops is a better idea, because you can't extract keys from the KMS.
- jwhitlark 8y ago
  This problem is one reason why it's important to separate CI from CD. If you do that, then circleci would only have what's needed to test and package it, and the CD can handle the rest, although ideally you'll have a third piece for secrets.