ReleaseEngineering/PuppetAgain/Secrets: Difference between revisions

No edit summary
(Move checks in their own section. Added a help subsection related to secret() and non-decrypted values)
 
(25 intermediate revisions by 11 users not shown)
Line 27: Line 27:


== Using EYAML ==
== Using EYAML ==
(This is pending completion of bug 891853)


Secrets are accessed via hiera, using hiera-eyaml.  That means that the secrets files are regular YAML files, but contain ciphertext enclosed by ENC[..] where secrets are protected.  The public and private keys used for this encryption are stored on the puppetmasters themselves.
Secrets are accessed via hiera, using hiera-eyaml.  That means that the secrets files are regular YAML files, but contain ciphertext enclosed by ENC[..] where secrets are protected.  The public and private keys used for this encryption are stored on the puppetmasters themselves.


To encrypt a new password, as root on a puppetmaster, give the name of the variable:
=== Encrypt strings (like passwords) ===


  eyaml -e -o block -p -n 'root_pw_hash!loaner'
As root on any puppetmaster, use:


then copy/paste the result into `/etc/hiera/secrets.yaml` or into your own `/etc/hiera/environments/<username>_secrets.yaml`.
  eyaml encrypt --pkcs7-private-key /etc/hiera/keys/private_key.pem --pkcs7-public-key /etc/hiera/keys/public_key.pem \
    --output examples --password -l 'foo'


where 'foo' is the name of the variable to set.  It will prompt for the password to encrypt.  The output will go to stdout, in 2 formats (all one line, multiline). Copy/paste whichever result format you prefer into `/etc/hiera/secrets.eyaml` or into your own `/etc/hiera/environments/<username>_secrets.eyaml`.
=== Encrypt files (e.g. private keys) ===
Pipe the contents of the file to the above command, and replace --password with --stdin, e.g.
  cat secret_file | eyaml encrypt --pkcs7-private-key /etc/hiera/keys/private_key.pem --pkcs7-public-key /etc/hiera/keys/public_key.pem \
    --output examples --stdin -l 'foo'
and update `/etc/hiera/secrets.eyaml` accordingly as per instructions above.
=== Check your YAML files ===
==== YAML Syntax ====
Double-check your work before saving -- if this file can't be parsed as valid yaml, all puppet runs will fail. A python one line syntax checker is:
  python -c "import yaml; f=open('secrets.eyaml','r'); yaml.load(f)" && echo "pass" || echo "FAIL"
When in doubt, run `eyaml --help` or `eyaml encrpyt --help`.
==== Secret values ====
To check the value of a secret, use 'hiera':
To check the value of a secret, use 'hiera':


   hiera -c /etc/puppet/hiera.yaml root_pw_saltedsha512
   hiera root_pw_saltedsha512
 
To check the value of a secret in `/etc/hiera/environments/<username>_secrets.eyaml`, use:
 
  hiera root_pw_saltedsha512 environment='<username>'
 
==== Help! secret() does not interpret my secret ====
 
Sometimes, secret() (or function_secret()) may return the raw value, instead of the decrypted one. This is very likely because of a bad copy and paste. In order to verify this, run the hiera command detailed in the section above. If the non-decrypted value is still returned, paste the encrypted value again. Some characters (like the closing ]) may be missing.
 
== User Environments ==
 
User environments use the same set of secrets as the production environment, so unless you are adding or modifying secrets, there's no need to mess with them.
 
Hiera also consults <tt>/etc/hiera/environments/$environment_secrets.eyaml</tt>, so if you *do* need to add or modify secrets, you can do so there and avoid modifying the production secrets file.  Note that environment secrets are not synced from master to master.


== Secrets ==
== Secrets ==
;'''root_pw_hash'''
Many secrets are documented in the modules that use them.
:linux md5 password hash for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Linux|where to find]])
 
;'''root_pw_pbkdf2'''
;google_api_key
:Mac OS X 10.8 entropy for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
:This is the Google API key; see {{bug|913041}}.
;'''root_pw_pbkdf2_salt'''
:Mac OS X 10.8 salt for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''root_pw_pbkdf2_iterations'''
:Mac OS X 10.8 iterations for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''root_pw_paddedsha1'''
:Mac OS X 10.6 password hash''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''root_pw_saltedsha512'''
:Mac OS X 10.7 password hash''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_hash'''
:linux md5 password hash for the builder user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Linux|where to find]])
;'''builder_pw_pbkdf2'''
:Mac OS X 10.8 entropy for the builder user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_pbkdf2_salt'''
:Mac OS X 10.8 salt for the builder user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_pbkdf2_iterations'''
:Mac OS X 10.8 iterations for the builder user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_paddedsha1'''
:Mac OS X 10.6 password hash''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_saltedsha512'''
:Mac OS X 10.7 password hash for the builder user''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_kcpassword_base64'''
:kcpassword-obfuscated cleartext of the builder user's password, for autologin on Darwin ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''builder_pw_vnc_base64'''
:base64-encoded version of the password that should appear in ''~/.vnc/passwd'' on Linux
;'''signer_pw_hash'''
:linux md5 password hash for the signer user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Linux|where to find]])
;'''signer_pw_pbkdf2'''
:Mac OS X 10.8 entropy for the signer user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''signer_pw_pbkdf2_salt'''
:Mac OS X 10.8 salt for the signer user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''signer_pw_pbkdf2_iterations'''
:Mac OS X 10.8 iterations for the signer user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''signer_pw_paddedsha1'''
:Mac OS X 10.6 password hash''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''signer_pw_saltedsha512'''
:Mac OS X 10.7 password hash for the signer user''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
;'''mozpool_inventory_url'''
: base URL for the Mozilla inventory
;'''mozpool_inventory_username'''
: LDAP username for the Mozilla inventory
;'''mozpool_inventory_password'''
: LDAP password for the Mozilla inventory
;'''mozpool_db_hostname'''
: DB hostname for the Mozilla inventory
;'''mozpool_db_database'''
: DB name for the Mozilla inventory
;'''mozpool_db_username'''
: DB username for the Mozilla inventory
;'''mozpool_db_password'''
: DB password for the Mozilla inventory
;'''balrog_password'''
: Balrog password (used in buildmaster)
;'''balrog_username'''
: Balrog username (used in buildmaster)
;buildbot_schedulerdb_database
: Scheduler database (used in buildmaster)
;buildbot_schedulerdb_hostname
: Scheduler database hostname (used in buildmaster)
;buildbot_schedulerdb_password
: Scheduler database password(used in buildmaster)
;buildbot_schedulerdb_username
: Scheduler database username (used in buildmaster)
;buildbot_statusdb_database
: Statusdb database (used in buildmaster)
;buildbot_statusdb_hostname
: Statusdb database hostname (used in buildmaster)
;buildbot_statusdb_password
: Statusdb database password (used in buildmaster)
;buildbot_statusdb_username
: Statusdb database username (used in buildmaster)
;jetperf_oauth_key
:jetperf oauth key (used in buildmaster)
;jetperf_oauth_secret
:jetperf oauth secret (used in buildmaster)
;linux_tests_password
:Buildbot slave password for linux test hosts (used in buildmaster)
;mac_tests_password
:Buildbot slave password for mac test hosts (used in buildmaster)
;prod_bulid_password
:Buildbot slave password for production build hosts (used in buildmaster)
;pulse_exchange
:pulse exchange (used in buildmaster)
;pulse_password
:pulse password (used in buildmaster)
;pulse_username
:pulse username (used in buildmaster)
;signing_server_dep_password
;signing_server_nightly_password
;signing_server_release_password
;signing_server_username
:credentials for signing servers (used in buildmaster)
;talos_oauth_key
:talos oauth key (used in buildmaster)
;talos_oauth_secret
:talos oauth secret (used in buildmaster)
;try_build_password
:Buildbot slave password for try build hosts (used in buildmaster)
;tuxedo_password
;tuxedo_username
:tuxedo credentials (used in buildmaster)
;puppetsync_pubkey
:the SSH public key for the puppetsync user, set up during the [[ReleaseEngineering/PuppetAgain/HowTo/Bootstrap a Puppetmaster|puppetmaster bootstrapping process]]
;puppetmaster_deploy_htpasswd
:the htpasswd-hashed password used to protect the puppetmaster deployment CGI. Generate with <tt>htpasswd -n - deploy</tt> and only include the portion after "deploy:" in the secrets file
;network_regexps
;network_regexps
:a list of regular expressions representing the local network.  This is used by the deployment CGI to limit access to known subnets.
:a list of regular expressions representing the trusted network containing all puppet nodes.  This is used, among other things, by the deployment CGI to limit access to known subnets.
;google_api_key
;mozilla_api_key
: API key used for google services (used by build slaves)
:This is the Mozilla API key; see {{bug|1003623}}.
;google_oauth_api_key
:This is the google oauth API key; see {{bug|1075675}}.
;crash_stats_api_token
: This is the token for uploading to crash-stats; {{bug|1119238}}
;adjust_sdk_token
: This is the token for the Adjust SDK, used for tracking Fennec installations; {{bug|1152871}}
;release s3 credentials
: boto config for doing release tasks; {{bug|1213790}}
 
== Related HOW TO's ==
* [[ReleaseEngineering/PuppetAgain/HowTo/Add_new_secrets|How To: Add new secrets]]
* [[ReleaseEngineering/PuppetAgain/HowTo/Change_secrets|How To: Change Secrets]]

Latest revision as of 17:02, 5 October 2016

In PuppetAgain, secrets are stored in Hiera.

Usage

To use a secret:

in manifests

class foo {
  if (secret('builder_password') == "")
     fail("missing password")
  }
}

If you need to interpolate the value into a string, you'll need to use a class-local variable.

in templates

This is a little verbose:

 <%= scope.function_secret(['signing_server_username']) %>

do not forget the [..] -- they are optional in puppet-2.7.x, but mandatory in 3.2.x.

Secrets Have Aspects

The secret() function will look for aspect-specific passwords for each aspect of the current host, using a suffix. For example, if a host has aspects "loaner" and "staging", then secret('root_password') will look for the following in hiera, using the first it finds:

 root_password!loaner
 root_password!staging
 root_password 

This is most useful around the 'staging' aspect, as it means that passwords for staging instances can be specified easily, with no conditionals in the module implementing the functionality.

Using EYAML

Secrets are accessed via hiera, using hiera-eyaml. That means that the secrets files are regular YAML files, but contain ciphertext enclosed by ENC[..] where secrets are protected. The public and private keys used for this encryption are stored on the puppetmasters themselves.

Encrypt strings (like passwords)

As root on any puppetmaster, use:

 eyaml encrypt --pkcs7-private-key /etc/hiera/keys/private_key.pem --pkcs7-public-key /etc/hiera/keys/public_key.pem \
    --output examples --password -l 'foo'

where 'foo' is the name of the variable to set. It will prompt for the password to encrypt. The output will go to stdout, in 2 formats (all one line, multiline). Copy/paste whichever result format you prefer into `/etc/hiera/secrets.eyaml` or into your own `/etc/hiera/environments/<username>_secrets.eyaml`.

Encrypt files (e.g. private keys)

Pipe the contents of the file to the above command, and replace --password with --stdin, e.g.

 cat secret_file | eyaml encrypt --pkcs7-private-key /etc/hiera/keys/private_key.pem --pkcs7-public-key /etc/hiera/keys/public_key.pem \
    --output examples --stdin -l 'foo'

and update `/etc/hiera/secrets.eyaml` accordingly as per instructions above.

Check your YAML files

YAML Syntax

Double-check your work before saving -- if this file can't be parsed as valid yaml, all puppet runs will fail. A python one line syntax checker is:

 python -c "import yaml; f=open('secrets.eyaml','r'); yaml.load(f)" && echo "pass" || echo "FAIL"

When in doubt, run `eyaml --help` or `eyaml encrpyt --help`.

Secret values

To check the value of a secret, use 'hiera':

 hiera root_pw_saltedsha512

To check the value of a secret in `/etc/hiera/environments/<username>_secrets.eyaml`, use:

 hiera root_pw_saltedsha512 environment='<username>'

Help! secret() does not interpret my secret

Sometimes, secret() (or function_secret()) may return the raw value, instead of the decrypted one. This is very likely because of a bad copy and paste. In order to verify this, run the hiera command detailed in the section above. If the non-decrypted value is still returned, paste the encrypted value again. Some characters (like the closing ]) may be missing.

User Environments

User environments use the same set of secrets as the production environment, so unless you are adding or modifying secrets, there's no need to mess with them.

Hiera also consults /etc/hiera/environments/$environment_secrets.eyaml, so if you *do* need to add or modify secrets, you can do so there and avoid modifying the production secrets file. Note that environment secrets are not synced from master to master.

Secrets

Many secrets are documented in the modules that use them.

google_api_key
This is the Google API key; see bug 913041.
network_regexps
a list of regular expressions representing the trusted network containing all puppet nodes. This is used, among other things, by the deployment CGI to limit access to known subnets.
mozilla_api_key
This is the Mozilla API key; see bug 1003623.
google_oauth_api_key
This is the google oauth API key; see bug 1075675.
crash_stats_api_token
This is the token for uploading to crash-stats; bug 1119238
adjust_sdk_token
This is the token for the Adjust SDK, used for tracking Fennec installations; bug 1152871
release s3 credentials
boto config for doing release tasks; bug 1213790

Related HOW TO's