-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initdata: migrate key release test cases to initdata #2006
Conversation
Tested for libvirt provider against sample TEE:
|
e7b28c8
to
3feaa88
Compare
I'll retest after the refactoring, I guess we can start reviewing also. |
Test and passed:
|
@mkulke may you help check whether the changes are OK for azure? |
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.
Generally it looks good to me. A couple of points that would make the review/future commit checks easier:
- Adding commit body explaining the why/how of the changes
- Squashing some of the commits together e.g. the current 4th commit and quite a lot of the 3rd commit, could be fixed up into the first commit for more clarity and grouping of the code.
Thanks for the great work!
Just re-thinking about it from a ux standpoint. Is it really needed to remove the support for AA_KBC_PARAMS ? |
@bpradipt any specific reason to keep |
That would be another configuration that we'd have to support and test. beyond a URI AA_KBC_PARAMs doesn't support certs or any current or future option for AA and CDH. I suspect AA_KBC_PARAMS will also be retired for kata-qemu (at least for cc_kbc). If we want to have a per-installation configuration for CAA to improve the UX, I suggest to (optionally) provide a default initdata.toml o via configmap, similar to the auth.json and use that one if no initdata is set as annotation on a pod. |
right, more config are adding in cdh.toml like |
@huoqifeng @mkulke thanks for clarifying. Providing default initData via configMap is a good option. |
It was not in my original plan, I added it as an item in #1985, hopefully, I can have time to do that. |
- migrate key release test cases to initdata - remove AA_KBC_PARAMS and aaKBCParams - use allow-all rego policy to make key release test run correctly Fixes: confidential-containers#1985 Signed-off-by: Qi Feng Huo <[email protected]>
- add global-initdata in configmap and parameters Fixes: confidential-containers#1985 Signed-off-by: Qi Feng Huo <[email protected]>
@bpradipt the |
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.
only a few comments, I'm not able to test the code currently. It would be good to also have a look at the current kata-qemu PR for init-data, since that PR is using the agent's SetInitData endpoint and this would probably overlap with what CAA is doing atm
- rename GLOBAL_INITDATA to INITDATA - rename CdhFilePath to CDHConfigPath - rename AaFilePath to AAConfigPath Fixes: confidential-containers#1985 Signed-off-by: Qi Feng Huo <[email protected]>
I'll keep monitoring the PR in kata-qemu. kata-containers/kata-containers#10163 |
- Validate the initdata passed in both from configmap and annotation Fixes: confidential-containers#1985 Signed-off-by: Qi Feng Huo <[email protected]>
if invalid initdata used, the error looks like:
|
Fixes: confidential-containers#1985 Signed-off-by: Qi Feng Huo <[email protected]>
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.
/lgtm
Thanks @huoqifeng
Fixes: #1985
AA_KBC_PARAMS
andpkg/aa
,pkg/cdh
etc.AA_KBC_PARAMS
INITDATA
in cmpeer-pods-cm
for default initdata for every Pod, Annotation in Pod will overwrite the settings inINITDATA
.because aa, cdh certificates might need kbs upgrade, so certificates and others support will be in separate PRs.