As we are due to update the puppet CA we will need to know all locations where the certificate is currently used. The following is a good list of places to start looking but may not be complete
- keys created using cergen
- users of base::expose_puppet_certs
- the few users we have that are referencing either puppet_ssldir() or manually hardcoding the /var/lib/puppet/ssl directory
- Any helm charts that need our CA cert: eventgate
The following services make reference to Puppet_Internal_CA.crt
- etcd: The systemd service references the puppet CA
- etcd::v3: also references this file for use in [[ https://github.com/wikimedia/puppet/blob/production/modules/etcd/templates/v3.etcd.default.erb#L28 | /etc/default/ectd ]]
- trafficserver: The main ATS config uses the puppet CA via [[ https://github.com/wikimedia/puppet/blob/production/hieradata/common/profile/trafficserver/backend.yaml#L281-L290 | $profile::trafficserver::backend::outbound_tls_settings ]]
- puppetdb: The puppetDB application references the public cert both in the postgress and jetty config
- its also the default for puppetmaster::pupetdb::ca_path
- prometheus - mysqld_exporter_config.py: references the file however this is a script and not a daemon so shouldn't need special handling
- debmonitor::client: this references and uses the puppet CA file however this runs from cron so shouldn't require special treatment
- profile::netbox: references the file and uses it to for ganeti, swift and puppetdb operations
- profile::cache::kafka::certificate: refrences this file and creates it under /etc/ssl/certs/ however this should not be required as its handled by base::certificates and update-ca-certificates which is installed everywhere
- postgresql: This module hard-codes the CA cert path
- k8s cube controler manager: has this file hard-coded
- calico: mentions this file in its systemd init file and its config file
- mariadb: uses this file in roles for phabricator, labsdb, tools, parsecache, misc, core-mysql, production and dbstore
- check_mariadb.py: references this file however as its a script it should not cause an issue
- backup_mariadb.py: references this file however as its a script it should not cause an issue
- rsync::server can reference the internal CA (when the stunnel wrapper is enabled). a simple systemctl reload stunnel should be sufficient on the servers using this
- rsyslog kafka output
- helm refences this certificate in the deployment charts repo