Key backup / restore format
Example:
{
“policy”:{
“name”:“local_owner_key__consensus”,
“keys”:{
“1”:{
“key”:“C3R5O8uAfrgv7sJmCMSLEp1R2HmkZtwdfGT/xVvZVvgCGo6TkWga/ojplJFMM+i2805X3CV7IRyNBCSJcr4AqQ==”,
“hmac_key”:null,
“time”:“2020-05-29T06:27:38.1233515Z”,
“ec_x”:null,
“ec_y”:null,
“ec_d”:null,
“rsa_key”:null,
“public_key”:“AhqOk5FoGv6I6ZSRTDPotvNOV9wleyEcjSwkiXK+AKk=”,
“convergent_version”:0,
“creation_time”:1590733658
}
},
“derived”:false,
“kdf”:0,
“convergent_encryption”:false,
“exportable”:true,
“min_decryption_version”:1,
“min_encryption_version”:0,
“latest_version”:1,
“archive_version”:1,
“archive_min_version”:0,
“min_available_version”:0,
“deletion_allowed”:false,
“convergent_version”:0,
“type”:2,
“backup_info”:{
“time”:“2020-05-29T06:28:48.2937047Z”,
“version”:1
},
“restore_info”:null,
“allow_plaintext_backup”:true,
“version_template”:“”,
“storage_prefix”:“”
}
}
This data structure is used to represent both policies read from Vault and written to Vault.
Thus the same Policy read, can then be written back after amending. Vault stores the rules or
per path policies in an encoded json blob, so that effectively means json within json, hence
the unusual semantics below.
{
rules: json!{
path: {
‘auth/’: { capabilities: [‘create’, ‘read’, ‘update’, ‘delete’, ‘list’, ‘sudo’] },
‘sys/auth/’: { capabilities: [‘create’, ‘read’, ‘update’, ‘delete’, ‘sudo’] },
}
}
}
Note: Vault claims rules is deprecated and policy should be used instead, but that doesn’t seem
to work and makes the reading asymmetrical from the writing.