We need to do a rolling restart of etcd before the old CA cert expires in a few months.
Codfw can be probably exempted for now given it will be reimaged in the next quarter.
We need to do a rolling restart of etcd before the old CA cert expires in a few months.
Codfw can be probably exempted for now given it will be reimaged in the next quarter.
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | jbond | T236277 Extend Puppet CA Expiry date | |||
Resolved | jbond | T237259 Document all uses of the puppetCA certificate | |||
Resolved | RLazarus | T237362 Rolling restart of etcd to pick up the renewed CA public certificate. |
Change 548241 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] puppet_ca: update puppet ca with a new certificate valid for 10 years
Correction:
All of this can happen asynchronously from the actual CA update as the service will keep working even if the CA file has changed.
Change 548241 merged by Jbond:
[operations/puppet@production] puppet_ca: update puppet ca with a new certificate valid for 10 years
Good news is we only need to do a rolling restart in eqiad, not in codfw, where we still don't use the ca for peer connections
Mentioned in SAL (#wikimedia-operations) [2019-12-10T10:55:37Z] <_joe_> restarting etcd on conf1004 T237362
Change 556647 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] etcd::client::globalconfig: add ca_cert
Have been trying to document some of the SSL findings and it appears to me that conftool client is currently preforming no SSL validations. Specificity
The conftool client does not configure a CA bundle to use. As conftool is using python4-etcd which in turn uses urllib3 it effectively means that validation is disabled
I have created a CR to update this
Change 556647 abandoned by Jbond:
[operations/puppet@production] etcd::client::globalconfig: add ca_cert
Reason:
supperseeded