ReleaseEngineering/PuppetAgain/Secrets: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Move checks in their own section. Added a help subsection related to secret() and non-decrypted values)
 
(31 intermediate revisions by 12 users not shown)
Line 1: Line 1:
In PuppetAgain, secrets are stored in <tt>manifests/extlookup/secrets.csv</tt>, which is org-specific and based on <tt>secrets-template.csv</tt> in the same directory,
In PuppetAgain, secrets are stored in Hiera.


== Usage ==
== Usage ==
Line 19: Line 19:
== Secrets Have Aspects ==
== Secrets Have Aspects ==


The <tt>secret()</tt> function will look for aspect-specific passwords for each [[ReleaseEngineering/PuppetAgain/Aspects|aspect]] of the current host, using a suffix.  For example, if a host has aspects "loaner" and "staging", then <tt>secret('root_password')</tt> will look for the following in the CSV file, using the first it finds:
The <tt>secret()</tt> function will look for aspect-specific passwords for each [[ReleaseEngineering/PuppetAgain/Aspects|aspect]] of the current host, using a suffix.  For example, if a host has aspects "loaner" and "staging", then <tt>secret('root_password')</tt> will look for the following in hiera, using the first it finds:
   root_password!loaner
   root_password!loaner
   root_password!staging
   root_password!staging
Line 26: Line 26:
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.
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.


== Variables ==
== Using EYAML ==
;'''root_pw_hash'''
 
:linux md5 password hash for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Linux|where to find]])
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.
;'''root_pw_pbkdf2'''
 
:Mac OS X 10.8 entropy for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
=== Encrypt strings (like passwords) ===
;'''root_pw_pbkdf2_salt'''
 
:Mac OS X 10.8 salt for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
As root on any puppetmaster, use:
;'''root_pw_pbkdf2_iterations'''
 
:Mac OS X 10.8 iterations for the root password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
  eyaml encrypt --pkcs7-private-key /etc/hiera/keys/private_key.pem --pkcs7-public-key /etc/hiera/keys/public_key.pem \
;'''root_pw_saltedsha512'''
    --output examples --password -l 'foo'
:Mac OS X 10.7 password hash''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
 
;'''builder_pw_hash'''
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`.
:linux md5 password hash for the builder user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Linux|where to find]])
 
;'''builder_pw_pbkdf2'''
=== Encrypt files (e.g. private keys) ===
: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'''
Pipe the contents of the file to the above command, and replace --password with --stdin, e.g.
: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'''
  cat secret_file | eyaml encrypt --pkcs7-private-key /etc/hiera/keys/private_key.pem --pkcs7-public-key /etc/hiera/keys/public_key.pem \
:Mac OS X 10.8 iterations for the builder user's password ''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
    --output examples --stdin -l 'foo'
;'''builder_pw_saltedsha512'''
 
:Mac OS X 10.7 password hash for the builder user''(No Default)'' ([[ReleaseEngineering/PuppetAgain/Modules/users#Darwin|where to find]])
and update `/etc/hiera/secrets.eyaml` accordingly as per instructions above.
;'''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]])
=== Check your YAML files ===
;'''builder_pw_vnc_base64'''
 
:base64-encoded version of the password that should appear in ''~/.vnc/passwd'' on Linux
==== YAML Syntax ====
;'''mozpool_inventory_url'''
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:
: base URL for the Mozilla inventory
 
;'''mozpool_inventory_username'''
  python -c "import yaml; f=open('secrets.eyaml','r'); yaml.load(f)" && echo "pass" || echo "FAIL"
: LDAP username for the Mozilla inventory
 
;'''mozpool_inventory_password'''
When in doubt, run `eyaml --help` or `eyaml encrpyt --help`.
: LDAP password for the Mozilla inventory
 
;'''mozpool_db_hostname'''
==== Secret values ====
: DB hostname for the Mozilla inventory
To check the value of a secret, use 'hiera':
;'''mozpool_db_database'''
 
: DB name for the Mozilla inventory
  hiera root_pw_saltedsha512
;'''mozpool_db_username'''
 
: DB username for the Mozilla inventory
To check the value of a secret in `/etc/hiera/environments/<username>_secrets.eyaml`, use:
;'''mozpool_db_password'''
 
: DB password for the Mozilla inventory
  hiera root_pw_saltedsha512 environment='<username>'
;'''balrog_password'''
 
: Balrog password (used in buildmaster)
==== Help! secret() does not interpret my secret ====
;'''balrog_username'''
 
: Balrog username (used in buildmaster)
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.
;buildbot_schedulerdb_database
 
: Scheduler database (used in buildmaster)
== User Environments ==
;buildbot_schedulerdb_hostname
 
: Scheduler database hostname (used in buildmaster)
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.
;buildbot_schedulerdb_password
 
: Scheduler database password(used in buildmaster)
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.
;buildbot_schedulerdb_username
 
: Scheduler database username (used in buildmaster)
== Secrets ==
;buildbot_statusdb_database
Many secrets are documented in the modules that use them. 
: Statusdb database (used in buildmaster)
 
;buildbot_statusdb_hostname
;google_api_key
: Statusdb database hostname (used in buildmaster)
:This is the Google API key; see {{bug|913041}}.
;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.
;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 ==
* [[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