You might have heard of past incidents from Twitter and GitHub, where internal systems handling sensitive data, such as passwords, accidentally expose those passwords in their internal logs. Wait, but they weren't stolen or seen by untrusted sources right? So, what's the problem? Simple. Exposing sensitive information in plain texts unknown to the operator can eventually lead to security breaches. Which can cause severe damage to your company or organization. Once our sensitive information is in plain text formats amongst mounds and mounds of data, it might make it difficult to identify or find over time. However, this could lead to openings needed by an attacker to compromise systems if found an old backups or mismanaged storage. In this video, we'll learn about the basics for protecting sensitive data in our continuous integration environment. We'll discuss risks associated with mismanagement of that data. We'll also cover features under Travis CI that help us with secrets management. It's important to understand the process for how to store sensitive information in an encrypted format during continuous integration processes and in analysis of data such as log files. We'll call these sensitive data secrets. As often as possible, these secrets should not have a long life on disk and only be accessible from memory of the executing language. When displaying commands to logs with sensitive information, it's important that we take advantage of continuous integration features to help us mask occurrences of the secrets. This avoids accidental leakage of plain text forms of secrets in our log files. Which might otherwise be used to debug or determine the final outcomes of our build. We should also use additional precautions to avoid exposing secrets in environment variables on containers to prevent them from being recorded in unsuspecting ways. It's often helpful to think of configuration management as a married pair of data composed of a key part and a value part. This is often referred to as a tuple, where the key part represents the name by which you will access the value, and the value part will be the actual data needed for your automation to perform some operation. The configuration management that secrets provide for us, are important to the functionality of our continuous integration environment, because they provide the data we need to influence the controls. They can help secure our code, artifacts and operating system, and communications among systems. They can also help us make logic decisions on when to take some action or not, such as publishing a build artifact. We can use configuration management system in conjunction with non-sensitive data to control the flow and function of our continuous integration jobs. Let's review some of the features Travis uses to manage secrets. First, Travis provides features to encrypt key value pairs that are considered sensitive data or secrets. Travis uses an asymmetric cryptographic pattern to encrypt that sensitive data and can generate private and public RSA key pairs. Travis will not share the private information but it will share the public information so that you can use commands such as the Travis encrypt, to create an encrypted version of the secret value. Travis will then use the private key information to decrypt the values configured during the build process. Next, the encrypted values are then stored in the.travis.yaml file, so that they can be used during the build process. Storing the value in a yml array under a secure key name which lives under the env key name will allow for the configuration to take effect. The key values that are then configure becomes environment variables that are easily accessible from any script within our build process. There are several ways to fetch the public key with the Travis encrypt command, including APIs accessible from Travis. However, the easiest way is to install the ruby gem called Travis and use the command called Travis pubkey-r owner/project. It's also good to be aware that there are several other methods to encrypt larger amounts of texts or sensitive information using fall encryption methods. Travis offers the command Travis encrypt-file to encrypt files with asymmetric encryption algorithm or better known as AES 256. Other techniques such as GPG encryption can also be used in combination with the first technique for encrypting a password and using GPG plus OpenSSL commands in the before step of our travis.yaml, so that we can configure our encryption strings. Travis will redact and obfuscate secret data that is encrypted with the tools that Travis provides. However, while running builds, it's important to be aware of potential chances of leaking your secrets in output such as build logs or files stored on disk. Values will be mast with secure tag text in our log files. Let's quickly go over some tips to avoid leaking those secrets while executing your continuous integration project. First, use the set+x in your script to stop output, especially when using the set-x or set-v command options in your script. These can be placed prior to scripted steps using sensitive information. Second, use automatic password generators or tools such as make password, to generate secret information. Third, if displaying environment variables, use env or printenv commands, so Travis can easily redact those values. Fourth, if you're printing secrets, do use commands such as echo $KEY, so that Travis can easily identify and redact values. Fifth, avoid mistakes in string escaping which might expose the secret values. Sixth, avoid too much command output which might contain secrets from your application logs. Seventh, in shell scripts, you can use the TRAP command to remove files on script exit when you receive the SIGTERM signals,so that files are automatically cleaned up that may contain sensitive information. Eighth, avoid commands that might expose secrets or wrap the commands with output that is redirected to /devnull. For example, my command with a secret redirected to /devnull with two redirected to ampersand one. In this example, the two which is the standard error, is redirected to one which is the standard output, and both are redirected to /devnull which avoids writing the output to a terminal or output buffer. With any continuous integration system, whenever using secrets, is always good to have an operational plan that allows for the rotation of those secrets on a periodic basis. Your teams should assess the risk associated with any secrets and factors that might require the team to rotate the values more aggressively. It's always good to have a scripted method for executing all secret value generation locally, so that rotation process is painless as possible and can be regularly executed. In this lesson, we took a deeper look at how Travis configuration management allows for the protection of sensitive data with Travis secrets management system. You should now have a deeper understanding of the importance of protecting our sensitive information and techniques to avoid sensitive data loss in logs or debugging output from our continuous integration environment. We should take precautions to continuously protect our continuous integration environment by regularly changing our secrets, and always be aware of potentials for changes that might leak our information to attackers. Having a strong understanding of secrets management system and best practices in how to use secretes gives us confidence in our continuous integration system. It ensures that the products being delivered are of high quality and secure. This in turn gives our developers confidence in making changes iteratively to provide better and faster features into solutions being delivered while getting the right workflow out of our continuous integration environment and setup.
