Hacker News Reader

Comment by mooreds | Hacker News Reader

Would you put secrets into a circleci environment variable? https://circleci.com/docs/2.0/env-vars/

That might be an improvement over checking in the json file, as I suspect (from a very brief look) that that is why the json file is checked in.

View on HN

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 (you can use that with GnuPG as well)

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?

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.

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.

Reply on news.ycombinator.com