-
Notifications
You must be signed in to change notification settings - Fork 88
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
CDH: kbs kms plugin should get aa_kbc_params from cdh config file if it's provided #593
Comments
Oh. This is messy. We need to fix this thoroughly in this thread. Current logic on CDH side flowchart TD;
A[Start] --> B{Is the configuration para is given?};
B -- Yes --> C[Read the configuration];
B -- No --> D[Use default configuration using offline_fs_kbc];
D --> E
C --> E{Try to read aa_kbc_params from env, kata's config, cmdline?}
E -- Yes --> G[Finish]
E -- No --> F[Set aa_kbc_param using CDH's config]
F --> G
The expected priority should be flowchart TD;
A[Start] --> B{Is the configuration para is given?};
B -- Yes --> C[Read the configuration];
B -- No --> D[Try to build a configuration];
D --> E{Try to read aa_kbc_params from env, kata's config, cmdline successfully?}
E -- Yes --> F[Use aa_kbc_params]
E -- No --> G[Use offline_fs_kbc]
F --> H[Generate other parts with default value]
G --> H[Generate other parts with default value]
H --> I[Finish]
C --> I
|
@Xynnn007 yes, the expected logic is what I want. Seems there are 2 separate path today:
Logs looks like as following when startup cdh:
|
This is a little messy but reasonable. In CDH config it will set ENV, thus then kms/kbs plugin could get it from env. |
CDH should firstly read config specified with commandline, and then env. aa_kbc_param should be firstly read directly from CDH's config file. If there is no config file, try to read from env and then kernel cmdline. If still no values found, use a default one with offline_fs_kbc. Close confidential-containers#593 Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
CDH should firstly read config specified with commandline, and then env. aa_kbc_param should be firstly read directly from CDH's config file. If there is no config file, try to read from env and then kernel cmdline. If still no values found, use a default one with offline_fs_kbc. Close confidential-containers#593 Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
CDH should firstly read config specified with commandline, and then env. aa_kbc_param should be firstly read directly from CDH's config file. If there is no config file, try to read from env and then kernel cmdline. If still no values found, use a default one with offline_fs_kbc. Close confidential-containers#593 Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
CDH should firstly read config specified with commandline, and then env. aa_kbc_param should be firstly read directly from CDH's config file. If there is no config file, try to read from env and then kernel cmdline. If still no values found, use a default one with offline_fs_kbc. Close confidential-containers#593 Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Flow like below causes the aa_kbc_params still comes from kata-agent configure file (
/etc/agent-config.toml
) even a cdh configure file provided via like-c cdh.toml
We need figure out an algorithm that cdh.toml will always take top priority as parameters when it's provided.
The text was updated successfully, but these errors were encountered: