Keeping Secrets Secret

This example is curtesy of Adyan Rios from the SEDAR team!

NEVER hard code any usernames and password login information in the code Use another application when possible (e.g., getPass or api or rstudioapi).

What are some examples of sensitive information in your R code?

  • Database links
  • Database username and passwords
  • AWS credentials

Example 1 - Using {dotenv} to hide internal database links:

  • This method provides a simple solution for teams that need to share access information internally but that information should not be committed to the repository.
  • Learn more here
  • Practice:
    • Create a project
    • Create a .env file defining visible public names for each sensitive piece of information
      • Ex. Visible_Public_Name = “hidden information”
      • Add a blank line at the end of this file. If not, R will have an issue processing it.
    • Make sure the .env file is not committed to the repository by adding ’*.env’ to a new line in the .gitignore file in your project folder.
    • After installing and loading the package, ensure your .env file has the correct file type and is in the correct working directory (in the project’s top level folder, or root directory).
    • Load hidden sensitive information stored in .env file using load_dot_env(.env)
    • Bring your hidden sensitive information into your global environment using Sys.getenv("Visible_Public_Name")

Example 2 - Using {keyring} to hide personal user names and passwords:

  • This method is suited for storing personal information that individuals on a team use to access their respective databases
  • “Each keyring can contain one or many secrets (keys). A key is defined by a service name and a password. Once a key is defined, it persists in the keyring store of the operating system. This means the keys persist beyond the termination of and R session. Specifically, you can define a key once, and then read the key value in completely independent R sessions… Note that all platforms have a default keyring, and key_get(), etc. will use that automatically.” keyring help files
  • Practice:
    • After installing and loading the package, store your username with password using key_set_with_value()
    • Bring your username and password into your code as needed with key_list() and key_get()
      • key_list() will show list of the services and usernames you have saved
      • key_list("test service")$username will give you just the username
      • get_key("test service", "test username") will provide the password associated with a given service and username
key_set_with_value(service = "test service", 
                   username = "test username",
                   password = "test password")

Be careful with your commits

  • Note that when you make a repository public, the history of commits will be visible to the public
    • When a project is ready to go public, consider scanning the historical commits for links, names, or passwords. Alternatively, start a new repo with the files that you are sure do not have user links, names, or passwords.
  • Practice using dotenv and keyring. The chance of sharing unintended information will be decreased once these tools are part of our respective workflows.

The information above was inspired by the following:

AWS

  • See git-secrets for ensuring that you don’t commit AWS credentials to a Git repo.

Secrets in code

  • If you find yourself in a situation, where you need to have credentials in code, don’t put that code in a local repository (connected to GitHub). Instead, source() a script from outside of the local repo that contains the credentials. This will ensure that it is never saved with the content for sharing with GitHub and will make it easy to systematically update passwords and usernames as needed.

Attribution

Adapted from material compiled by Adyan Rios from the SEDAR.