-
Notifications
You must be signed in to change notification settings - Fork 58
coco_keyprovider: rewrite the README.md #200
coco_keyprovider: rewrite the README.md #200
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really useful.
I made one small comment but this is a big improvement no matter what.
coco_keyprovider/README.md
Outdated
- Use sample key provider to encrypt an image | ||
#### Example 2: encrypting for Offline fs, Offline SEV and Online SEV KBC | ||
|
||
For `offline-fs-kbc`, `offline-sev-kbc` and `online-sev-kbc` the KBS address shoud be set to "default". In common, they need a key upfront to encrypt the image: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to add a line saying that this key can then be provisioned to the kbs.
Also, I don't think default
is required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, default
is not required but it should have a <repository>
as the error message below implies:
2023-05-15T23:15:52Z DEBUG coco_keyprovider::enc_mods] normalize key id kbs:///key/key_id1
FATA[0004] copying system image from manifest list: Unable to finalize encryption: error while retrieving keyprovider protocol grpc output: Error from grpc method: rpc error: code = Internal desc = encrypt failed: Resource path kbs:///key/key_id1 must follow one of the following formats:
'kbs:///<repository>/<type>/<tag>'
'kbs://<kbs-addr>/<repository>/<type>/<tag>'
'<kbs-addr>/<repository>/<type>/<tag>'
'/<repository>/<type>/<tag>'
Can be anything, subject to user's preference? Or it will be used by some component to whatever reason and should have a correct value (e.g. be the registry repo where the image will be pushed to)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fitzthum re-wrote that paragraph. Better now?
I also added an explanation of kid
format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks for explaining this.
coco_keyprovider/README.md
Outdated
} | ||
} | ||
], | ||
"Env": [ | ||
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" | ||
] | ||
} | ||
``` | ||
|
||
We can see that the layer's `mediaType` is `application/vnd.oci.image.layer.v1.tar+gzip+encrypted`, which means the layer is encrypted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/mediaType/MIMEType/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
coco_keyprovider/README.md
Outdated
- Use sample key provider to encrypt an image | ||
#### Example 2: encrypting for Offline fs, Offline SEV and Online SEV KBC | ||
|
||
For `offline-fs-kbc`, `offline-sev-kbc` and `online-sev-kbc` the KBS address shoud be set to "default". In common, they need a key upfront to encrypt the image: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: shoud
```bash | ||
$ skopeo inspect oci:busybox_encrypted:default | jq -r '.LayersData[].Annotations."org.opencontainers.image.enc.keys.provider.attestation-agent"' | base64 -d | ||
{"kid":"kbs:///default/key/key_id1","wrapped_data":"3EgQbw6CRV4bik2sK3tkMJpycVWDUeuHcYngWkdWu+K0AzCPf7tYBCZ1HlWialfgEtD1t0nssva/5hIEmLOmvcarvHiMtDrDIacRHtINLqrQJBeF53d813u/GC+zk/tGxAweWze4uKEQ8mjshr3+bbYwEHJuQr3ugqiWE9g5HguMGVeEgfQydvu/SfeX2fRy4PZkFr8VnD7Z4k5HWVHZMf4SmhIHaRyUkShOpxuWPpnx9oHhbR0GJwfpoyxO4rtJXi2885qgU2kGUhZ6E2Snh+A=","iv":"4ezLbeMQdEkY/iuF","wrap_type":"A256GCM"} | ||
$ skopeo inspect oci:busybox_encrypted:default | jq -r '.LayersData[].Annotations."org.opencontainers.image.enc.pubopts"' | base64 -d | ||
{"cipher":"AES_256_CTR_HMAC_SHA256","hmac":"P3O+CYaDcR6BmxJouiEWIX3NW7Yv6NTpJyvhe6PflP8=","cipheroptions":{}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just making sure I understand this:
"wrap_type":"A256GCM"
means the layer-encryption-key is encrypted with AES-256-GCM"cipher":"AES_256_CTR_HMAC_SHA256"
means that the layer is encrypted with AES-256-CTR
is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that is correct.
d126fa5
to
76cc268
Compare
Applied major changes in coco_keyprovider's README.md aiming to explain basic concepts and ease for non-experts on the domain. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
76cc268
to
2f6b9cf
Compare
@dubek can I get you approval too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks @wainersm .
While ago I had to encrypt an image to use with SEV and I got some difficult to understand the new coco_keyprovider by only reading the README. As I learned I took some notes and now I am flushing on the README.
Applied major changes in coco_keyprovider's README.md aiming to explain basic concepts and ease for non-experts on the domain.