在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:StackExchange/blackbox开源软件地址:https://github.com/StackExchange/blackbox开源编程语言:Go 58.4%开源软件介绍:BlackBoxSafely store secrets in a VCS repo (i.e. Git, Mercurial, Subversion or Perforce). These commands make it easy for you to Gnu Privacy Guard (GPG) encrypt specific files in a repo so they are "encrypted at rest" in your repository. However, the scripts make it easy to decrypt them when you need to view or edit them, and decrypt them for use in production. Originally written for Puppet, BlackBox now works with any Git or Mercurial repository. A slide presentation about an older release is on SlideShare. Join our mailing list: https://groups.google.com/d/forum/blackbox-project Table of Contents
OverviewSuppose you have a VCS repository (i.e. a Git or Mercurial repo) and certain files contain secrets such as passwords or SSL private keys. Often people just store such files "and hope that nobody finds them in the repo". That's not safe. With BlackBox, those files are stored encrypted using GPG. Access to the VCS repo without also having the right GPG keys makes it worthless to have the files. As long as you keep your GPG keys safe, you don't have to worry about storing your VCS repo on an untrusted server. Heck, even if you trust your server, now you don't have to trust the people that do backups of that server, or the people that handle the backup tapes! Rather than one GPG passphrase for all the files, each person with access has their own GPG keys in the system. Any file can be decrypted by anyone with their GPG key. This way, if one person leaves the company, you don't have to communicate a new password to everyone with access. Simply disable the one key that should no longer have access. The process for doing this is as easy as running 2 commands (1 to disable their key, 1 to re-encrypt all files.) Automated processes often need access to all the decrypted files. This is easy too. For example, suppose Git is being used for Puppet files. The master needs access to the decrypted version of all the files. Simply set up a GPG key for the Puppet master (or the role account that pushes new files to the Puppet master) and have that user run Getting started
Why is this important?OBVIOUSLY we don't want secret things like SSL private keys and passwords to be leaked. NOT SO OBVIOUSLY when we store "secrets" in a VCS repo like Git or Mercurial, suddenly we are less able to share our code with other people. Communication between subteams of an organization is hurt. You can't collaborate as well. Either you find yourself emailing individual files around (yuck!), making a special repo with just the files needed by your collaborators (yuck!!), or just deciding that collaboration isn't worth all that effort (yuck!!!). The ability to be open and transparent about our code, with the exception of a few specific files, is key to the kind of collaboration that DevOps and modern IT practitioners need to do. Installation Instructions
Commands
CompatibilityBlackBox automatically determines which VCS you are using and does the right thing. It has a plug-in architecture to make it easy to extend to work with other systems. It has been tested to work with many operating systems.
To add or fix support for a VCS system, look for code at the end of To add or fix support for a new operating system, look for the case statements in Using BlackBox on WindowsBlackBox can be used with Cygwin or MinGW. Protect the line endingsBlackBox assumes that If you use Git, add the following lines to your
The latest version of CygwinCygwin support requires the following packages: Normal operation:
Development (if you will be adding code and want to run the confidence test)
MinGWMinGW (comes with Git for Windows) support requires the following: Normal operation:
Development:
How is the encryption done?GPG has many different ways to encrypt a file. BlackBox uses the mode that lets you specify a list of keys that can decrypt the message. If you have 5 people ("admins") that should be able to access the secrets, each creates a GPG key and adds their public key to the keychain. The GPG command used to encrypt the file lists all 5 key names, and therefore any 1 key can decrypt the file. To remove someone's access, remove that admin's key name (i.e. email address) from the list of admins and re-encrypt all the files. They can still read the .gpg file (assuming they have access to the repository) but they can't decrypt it any more. What if they kept a copy of the old repo before you removed access? Yes, they can decrypt old versions of the file. This is why when an admin leaves the team, you should change all your passwords, SSL certs, and so on. You should have been doing that before BlackBox, right? Why don't you use symmetric keys? In other words, why mess with all this GPG key stuff and instead why don't we just encrypt all the files with a single passphrase. Yes, GPG supports that, but then we are managing a shared password, which is fraught with problems. If someone "leaves the team" we would have to communicate to everyone a new password. Now we just have to remove their key. This scales better. How do automated processes decrypt without asking for a password? GPG requires a passphrase on a private key. However, it permits the creation of subkeys that have no passphrase. For automated processes, create a subkey that is only stored on the machine that needs to decrypt the files. For example, at Stack Exchange, when our Continuous Integration (CI) system pushes a code change to our Puppet masters, they run If you use Puppet, why didn't you just use hiera-eyaml? There are 4 reasons:
What does this look like to the typical user?
Wait... it can be even easier than that! Run How to use the secrets with Ansible?Ansible Vault provides functionality for encrypting both entire files and strings stored within files; however, keeping track of the password(s) required for decryption is not handled by this module. Instead one must specify a password file when running the playbook. Ansible example for password file:
Alternatively, one can specify this in the How to use the secrets with Puppet?Entire files:Entire files, such as SSL certs and private keys, are treated just like regular files. You decrypt them any time you push a new release to the puppet master. Puppet example for an encrypted file:
Small strings:Small strings, such as passwords and API keys, are stored in a hiera yaml file, which you encrypt with Setup: Configure
In blackbox.yaml specify:
In your Puppet Code, access the password as you would any hiera data:
The variable How to enroll a new file into the system?
Multiple file names can be specified on the command line: Example 1: Register 2 files:
Example 2: Register all the files in
How to remove a file from the system?This happens quite rarely, but we've got it covered:
How to indoctrinate a new user into the system?FYI: Your repo may use
To join the list of people that can edit the file requires three steps; You create a GPG key and add it to the key ring. Then, someone that already has access adds you to the system. Lastly, you should test your access. Step 1: NEW USER creates a GPG key pair on a secure machine and adds to public keychain.If you don't already have a GPG key, here's how to generate one:
WARNING: New versions of GPG generate keys which are not understood by old versions of GPG. If you generate a key with a new version of GPG, this will cause problems for users of older versions of GPG. Therefore it is recommended that you either assure that everyone using Blackbox have the exact same version of GPG, or generate GPG keys using a version of GPG as old as the oldest version of GPG used by everyone using Blackbox. Pick defaults for encryption settings, 0 expiration. Pick a VERY GOOD passphrase. Store a backup of the private key someplace secure. For example, keep the backup copy on a USB drive that is locked in safe. Or, at least put it on a secure machine with little or no internet access, full-disk-encryption, etc. Your employer probably has rules about how to store such things. FYI: If generating the key is slow, this is usually because the system
isn't generating enough entropy. Tip: Open another window on that
machine and run this command: Now that you have a GPG key, add yourself as an admin:
...where "KEYNAME" is the email address listed in the gpg key you created previously. For example:
When the command completes successfully, instructions on how to commit these changes will be output. Run the command as given to commit the changes. It will look like this:
Then push it to the repo:
NOTE: Creating a Role Account? If you are adding the pubring.gpg of a role account, you can specify the directory where the pubring.gpg file can be found as a 2nd parameter: Step 2: EXISTING ADMIN adds new user to the system.Ask someone that already has access to re-encrypt the data files. This gives you access. They simply decrypt and re-encrypt the data without making any changes. Pre-check: Verify the new keys look good.
For example, examine the key name (email address) to make sure it conforms to corporate standards. Import the keychain into your personal keychain and reencrypt:
Push the re-encrypted files:
Step 3: NEW USER tests.Make sure you can decrypt a file. (Suggestion: Keep a dummy file in VCS just for new people to practice on.) How to remove a user from the system?Simply run Example:
When the command completes, you will be given a reminder to check in the change and push it. Note that their keys will still be in the key ring, but they will go unused. If you'd like to clean up the keyring, use the normal GPG commands and check in the file. FYI: Your repo may use
FYI: Your repo may use The key ring only has public keys. There are no secret keys to delete. Remember that this person did have access to all the secrets at one time. They could have made a copy. Therefore, to be completely secure, you should change all passwords, generate new SSL keys, and so on just like when anyone that had privileged access leaves an organization. Where is the configuration stored? .blackbox vs. keyrings/liveBlackbox stores its configuration data in the All documentation refers to You can convert an old repo by simply renaming the directory:
There is no technical reason to convert old repos except that it is less confusing to users. This change was made in commit 60e782a0, release v1.20180615. The details:
Enabling BlackBox For a RepoOverview: To add "blackbox" to a git or mercurial repo, you'll need to do the following:
FYI: Your repo may use Run the initialize script.You'll want to include blackbox's "bin" directory in your PATH:
If you're using antigen, adding For the first user, create a GPG key and add it to the key ring.Follow the instructions for "How to indoctrinate a new user into the system?". Only do Step 1. Once that is done, is a good idea to test the system by making sure a file can be added to the system (see "How to enroll a new file into the system?"), and a different user can decrypt the file. Make a new file and register it:
Decrypt it:
Re-encrypt it:
You should only see The next step is to commit Set up automated users or "role accounts"i.e. This is how a Puppet Master can have access to the unencrypted data. FYI: Your repo may use An automated user (a "role account") is one that that must be able to decrypt without a passphrase. In general you'll want to do this for the user that pulls the files from the repo to the master. This may be automated with Jenkins CI or other CI system. GPG keys have to have a passphrase. However, passphrases are optional on subkeys. Therefore, we will create a key with a passphrase then create a subkey without a passphrase. Since the subkey is very powerful, it should be created on a very secure machine. There's another catch. The role account probably can't check files into Git/Mercurial. It probably only has read-only access to the repo. That's a good security policy. This means that the role account can't be used to upload the subkey public bits into the repo. Therefore, we will create the key/subkey on a secure machine as yourself. From there we can commit the public portions into the repo. Also from this account we will export the parts that the role account needs, copy them to where the role account can access them, and import them as the role account. ProTip: If asked to generate entropy, consider running this on the same machine in another window: For the rest of this doc, you'll need to make the following substitutions:
NOTE: This should be more automated/scripted. Patches welcome. On SECUREHOST, create the puppet master's keys:
NOTE: Rather than a real email address, use the username@FQDN of the host the key will be used on. If you use this role account on many machines, each should have its own key. By using the FQDN of the host, you will be able to know which key is which. In this doc, we'll refer to username@FQDN as $KEYNAME Save the passphrase somewhere safe! Create a sub-key that has no password:
Now securely export this directory to NEWMASTER:
On NEWMASTER, receive the new GnuPG config:
Back on SECUREHOST, add the new email address to .blackbox/blackbox-admins.txt:
Verify that secring.gpg is a zero-length file. If it isn't, you have somehow added a private key to the keyring. Start over.
Commit the recent changes:
Regenerate all encrypted files with the new key:
On NEWMASTER, import the keys and decrypt the files:
ProTip: If you get "gpg: decryption failed: No secret key" then you forgot to re-encrypt blackbox.yaml with the new key. On SECUREHOST, securely delete your files:
Also shred any other temporary files you may have made. |