5
11 Comments

Committing secrets to a public Repo :(

How do you prevent committing secrets to a pubic repo? Or any repo?

I understand all the assistance around finding keys once this happens but how do you prevent it? Is there an alternative to git secrets?

on August 18, 2019
  1. 2

    Basically setup a workflow/app to prevent this. Env files are nice and help eliminate this concern as long as you have .gitignore setup correctly.

    1. 1

      What can I or a coworker do beyond this? If a team member has a habit of being forgetful what are our other options?

      What if they’re working on a new service or feature and accidentally hard coded the variable or forgot to update the .gitignore?

      1. 1

        Google Tools like git-secrets

  2. 2

    The best way is to make sure all secrets are stored in variables that are called either ..._SECRET or ... _KEY. Then define those variables in a credentials configuration file that gets loaded at run-time. Finally add the credentials file to .gitignore.

    1. 1

      What can I or a coworker do beyond this? If a team member has a habit of being forgetful what are our other options?

      1. 1

        Putting all the credentials in one file that is listed in .gitignore cuts down 99% of the issue with forgetfulness.

        The next step you can take is to always have your senior / security / detail-oriented engineer do the first commit on integrating a 3rd party service. Once you pass the first months of development, the chances that you will be integrating a 3rd party service (hence require a new key) are slim and far apart.

        Lastly make sure everyone works with their own registered developper accounts, keeping production keys on production machines. For example, we make sure here that developper sign up with Stripe and work with their own account test keys. If by accident, it would happen a dev commits their keys, then production is not compromised. Second this kind of situation would start a commit ping-pong (I commit my key, you commit your key) that would lead to a resolution quite rapidly.

      2. 1

        Why not private repos?

        1. 1

          Private is a good default but generally what shouldn’t happen, eventual happens. I’m already doing most of the advice offered here but what I really want is a pre-commit hook or something that runs as part of the build. Even in a private repo.

  3. 1

    If I understand your question properly...
    As for I'm working with Python, there is a great thing called a virtual environment. This guy allows all the secrets living on your computer in a special place (activate.bat). The config.py file just refers to them, and there is nothing secret in referring.
    So, virtual env never goes to github and everyone who clones the project, should create their own virtual env and fill it up with secrets.

  4. 1

    In my workflow, I do it like this:

    • secrets go in their own file that's ignored by version control
    • my CI/CD test runner has an SSH key for the production box (stored in Gitlab project environment vars)
    • during the build, the script SCPs the secrets file to the production environment
    • only the user owning the web server process can access the secrets file

    Doing it this way, no environment variables need to be loaded on the box at runtime (which is useful if you have compile-time configuration), nothing secret is stored in version control and you don't personally need to remember any configs.

  5. 1

    you can setup a ci/cd pipeline to launch, check and alert on this, but there is no way to prevent this unless you change the way secrets are handled during development, devops tasks etc. Unless plant a chip in everyone's brain with a shocker :p

    -- not trying to sell but:
    The product I launched is a devops secrets manager that allow you to run scripts, apps etc with secrets injected as environment variables, very easy to setup and use. Ping me if you'd like more info or a live demo :) A small group of devs and I already use it everyday and so far Ive never had an issue with creds ending up in code by accident.