Update patch set 1
Patch Set 1:
(5 comments)
Patch-set: 1
CC: Gerrit User 5314 <5314@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Attention: {"person_ident":"Gerrit User 27665 \u003c27665@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_5314\u003e replied on the change"}
This commit is contained in:
Gerrit User 5314
Gerrit Code Review
parent
af72f4a425
commit
9a8e3074a5
|
|
@ -34,6 +34,69 @@
|
|||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": false,
|
||||
"key": {
|
||||
"uuid": "0cf08187_29fdd590",
|
||||
"filename": "/PATCHSET_LEVEL",
|
||||
"patchSetId": 1
|
||||
},
|
||||
"lineNbr": 0,
|
||||
"author": {
|
||||
"id": 5314
|
||||
},
|
||||
"writtenOn": "2024-04-12T12:35:51Z",
|
||||
"side": 1,
|
||||
"message": "My primary concern is that the way cinder handles keys and secrets may not address some of the use cases you describe, so it would be good to have more clarity on that. See comments inline.",
|
||||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
"uuid": "710a0bf6_c929c836",
|
||||
"filename": "specs/2024.2/byok-for-cinder.rst",
|
||||
"patchSetId": 1
|
||||
},
|
||||
"lineNbr": 18,
|
||||
"author": {
|
||||
"id": 5314
|
||||
},
|
||||
"writtenOn": "2024-04-12T12:35:51Z",
|
||||
"side": 1,
|
||||
"message": "It would be helpful if you could point to some legal requirements or security specifications that require this so that we can understand exactly what is needed, because this may entail a complete redesign of the way cinder does key handling. (See my comment below in the \"Proposed change\" section.)",
|
||||
"range": {
|
||||
"startLine": 18,
|
||||
"startChar": 247,
|
||||
"endLine": 18,
|
||||
"endChar": 331
|
||||
},
|
||||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
"uuid": "a4f3aa7e_b4fda64c",
|
||||
"filename": "specs/2024.2/byok-for-cinder.rst",
|
||||
"patchSetId": 1
|
||||
},
|
||||
"lineNbr": 31,
|
||||
"author": {
|
||||
"id": 5314
|
||||
},
|
||||
"writtenOn": "2024-04-12T12:35:51Z",
|
||||
"side": 1,
|
||||
"message": "Actually, we have a Big Problem here, namely, that cinder assumes that there is a 1-1 correspondence between a Secret in the Key Manager and a cinder resource (e.g., a volume, but also a volume uploaded to Glance as an image). The reason for this is so that cinder (or glance) can delete the Secret when the resource is deleted (otherwise, the Key Manager gets filled up with Secrets that aren\u0027t being used for anything).\n\nSo we need to distinguish between a Secret and the Key (that is, a Secret is a thing in Barbican that has a uuid, the *value* of the Secret, which is the Key). When you Bring Your Own Key to create a volume, we can use the Key value that is in Barbican, but we will create a *different* Secret that is specific to this volume (but which has the value you specified). So it will have the same Key, just identified by a different Secret uuid.\n\nWhat this means for your proposal is that an end user is not going to be able to tell from the encryption_key_id that\u0027s returned by the mv 3.64+ volume-show call what Key is being used. So you need to review the Use Cases you identified above and see which ones are not possible given the current way cinder does key handling, and whether it\u0027s acceptable to address fewer use cases, or whether we need to re-design the way cinder does key handling.\n\nI am especially interested in whether any legal requirements or security specifications that require Bring Your Own Key would find the current scheme acceptable.",
|
||||
"range": {
|
||||
"startLine": 31,
|
||||
"startChar": 0,
|
||||
"endLine": 31,
|
||||
"endChar": 57
|
||||
},
|
||||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
|
|
@ -85,6 +148,29 @@
|
|||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
"uuid": "b2a17fce_bae9f895",
|
||||
"filename": "specs/2024.2/byok-for-cinder.rst",
|
||||
"patchSetId": 1
|
||||
},
|
||||
"lineNbr": 54,
|
||||
"author": {
|
||||
"id": 5314
|
||||
},
|
||||
"writtenOn": "2024-04-12T12:35:51Z",
|
||||
"side": 1,
|
||||
"message": "This is a good point and we need to think it through some more. Check with Eric Harney about this, he was working on re-keying encrypted volumes under specific circumstances. I\u0027m not sure if the current code would support creating a volume and giving the source_volid of an existing encrypted volume and being able to change the key value of the new volume.",
|
||||
"range": {
|
||||
"startLine": 54,
|
||||
"startChar": 4,
|
||||
"endLine": 54,
|
||||
"endChar": 128
|
||||
},
|
||||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
|
|
@ -102,6 +188,24 @@
|
|||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
"uuid": "326d8f9e_c7199981",
|
||||
"filename": "specs/2024.2/byok-for-cinder.rst",
|
||||
"patchSetId": 1
|
||||
},
|
||||
"lineNbr": 55,
|
||||
"author": {
|
||||
"id": 5314
|
||||
},
|
||||
"writtenOn": "2024-04-12T12:35:51Z",
|
||||
"side": 1,
|
||||
"message": "I agree with Markus, maybe a failure to contact Barbican should return a 503 (Service Unvailable) with a message like \"Key Manager Service is Unavailable\".\n\nFor the case where the specified volume type doesn\u0027t support encryption, I think a 400 (not 409) is correct, because the user needs to make a different request (not retry later when the resource is in a different state).",
|
||||
"parentUuid": "159ede71_bfa4da2b",
|
||||
"revId": "acbd671fcd3471637898c6b9f4a256cc2c9727b5",
|
||||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||||
},
|
||||
{
|
||||
"unresolved": true,
|
||||
"key": {
|
||||
|
|
|
|||
Loading…
Reference in New Issue