get-csr action should be labeled as destructive
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
vault-charm | Status tracked in Trunk | |||||
1.7 |
In Progress
|
High
|
Jadon Naas | |||
1.8 |
In Progress
|
High
|
Jadon Naas | |||
Trunk |
Fix Released
|
High
|
Liam Young |
Bug Description
I recently hit an issue on a cloud where the vault leader was in a blocked state with this status:
"Missing CA cert"
Upon investigation, I saw that the root-ca value, which was previously set via an upload-signed-csr action, was no longer set in the leader data; "leader-get" didn't return anything for it.
I found that breaking and re-establishing a certificates relation with another app (I used heat) would result in no certificate data coming across to that app, and thus that app being unable to start in HTTPS mode.
I traced this backwards, and found in the Juju audit logs that somoene had run the get-csr action a few months ago.
get-csr sounds benign, but it has some important side effects which affect how the charm operates:
clear_
hookenv.
{'root-ca': None})
Unfortunately, the above has proven to not be benign, as described.
Can this be labeled somehow as destructive, or perhaps extra parameters added or something, so this doesn't end up wiping the root-ca leader value which is used as a flag by other parts of the charm - and which its absence blocks charm.vault.
Changed in vault-charm: | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Liam Young (gnuoy) |
subscribing field-high. We've hit this again; adding an extra action parameter as a safety mechanism would be tremendously useful