agent need to set image-rs and attestation agent config in a proper place about enclave-cc HOT 19 CLOSED

1. at payload image build time, that would be a default config(e.g.: image signature validation config) or even empty config(e.g: KBS config)
2. at runtime deployment time, that would be a cluster/tenant level config, requires operator to inject agent config into the agent enclave container bundle before deployment of the runtime according to runtime deployment config file(e.g: https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml)
3. at agent enclave attestation time, that would be a pod/sandbox level config and may require help from a third party to send trusted config into the enclave before libos/agent starts
4. at workload deployment time, that would be a application specific config, that requires shim to manipulate the agent enclave container bundle OCI spec

Currently we are supporting phase 2(configured in deployment runtime) in v0.3.0 release.
Due to phase 3 and phase 4 still have various of dependencies on other components, the release plans are TBD, I prefer to close this issue.

from enclave-cc.

looking at the current agent code, the agent configuration file parse should happen right after the agent is running and before doing anything else

from enclave-cc.

I'm not sure why ENABLE_SECURITY_VALIDATE is configurable through ENV variable. I mean the behavior of ENABLE_SECURITY_VALIDATE should be mandatory, rather than optional or configurable, unless the image-rs is built as debug mode.

from enclave-cc.

there is discussion in confidential-containers/image-rs#60 and kata-containers/kata-containers#4888 talking about the default behavior of signature validation
the intended solution is by default the validation is enabled but open a config option in agent config(both kata-agent and enclave-agent) to let user be able to disable the validation after serious consideration of the consequences or simply to easy get started on CoCo(thinking of the image signing solution in CoCo is both complicated and not completed yet)

Also currently image-rs does not provide a configurable interface for the enable/disable of validation, hence the ENV var is used to pass the info

from enclave-cc.

there is discussion in confidential-containers/image-rs#60

based on this I believe this issue can be closed. @hairongchen agree?

from enclave-cc.

there is discussion in confidential-containers/image-rs#60

based on this I believe this issue can be closed. @hairongchen agree?

according to discussion at confidential-containers/image-rs#60 (comment), we'll refine the agent to meet kata-agent behavior, @HaokunX-intel is working on it now.

from enclave-cc.

I saw that thread and it looks env variables are not going to be used so this issue is not valid. are you OK with closing?

from enclave-cc.

Thanks for the info, updated the issue to adhere to what's really needed, and when the change to agent is merged, we can close it.

from enclave-cc.

Looking at the issue from another perspective:

as shown in above graph, there are four timing that I can think of to inject a agent config:

1. at payload image build time, that would be a default config(e.g.: image signature validation config) or even empty config(e.g: KBS config)
2. at runtime deployment time, that would be a cluster/tenant level config, requires operator to inject agent config into the agent enclave container bundle before deployment of the runtime according to runtime deployment config file(e.g: https://github.com/confidential-containers/operator/blob/main/config/samples/enclave-cc/base/ccruntime-enclave-cc.yaml)
3. at agent enclave attestation time, that would be a pod/sandbox level config and may require help from a third party to send trusted config into the enclave before libos/agent starts
4. at workload deployment time, that would be a application specific config, that requires shim to manipulate the agent enclave container bundle OCI spec

if confidentiality is required for the config, then the config can be send in secure channel in any form, if the config confidentiality is not required, then the config can be send in public channel and libos can use it after a integrity check.

Now, an immediate requirement here is in operator CI, we want to enable agent to abstract keys and other resources from external KBS(now EAA+Verdictd) to implement a solid user case including image signature verification and decryption. In this context, we want a method to config the agent with external KBS info.

Looking at current status, I'd propose we inject the agent config at time 2: at runtime deployment time

Let me know your thoughts.

@jiazhang0 @mkbhanda @dcmiddle @mythi

from enclave-cc.

tasks to do

• rats-tls build into agent bundle to support EAA KBC (#48)
• operator to set agent config during runtime install (#83 and confidential-containers/operator#147)
• agent to read config file #70

@jiere @HaokunX-intel

from enclave-cc.

operator to set agent config during runtime install

if we agree on the environment variable approach, there's nothing the operator needs to do. I guess this should ready: enclave-cc payload installer to set agent config?

agent to read config file

this is already supported

from enclave-cc.

if we agree on the environment variable approach, there's nothing the operator needs to do. I guess this should ready: enclave-cc payload installer to set agent config?

I think currently image-rs will not use env var to control image-rs' behavior according to confidential-containers/image-rs#60 (comment)

agent to read config file

this is already supported

yes, it is supported but has a bug related to read timing and @HaokunX-intel is on it

from enclave-cc.

if we agree on the environment variable approach, there's nothing the operator needs to do. I guess this should ready: enclave-cc payload installer to set agent config?

I think currently image-rs will not use env var to control image-rs' behavior according to confidential-containers/image-rs#60 (comment)

I was referring to how we make /etc/decrypt_config.conf available to agent enclave.

agent to read config file

this is already supported

yes, it is supported but has a bug related to read timing and @HaokunX-intel is on it

which issue id is that?

from enclave-cc.

I was referring to how we make /etc/decrypt_config.conf available to agent enclave.

can you be more specific on this?

which issue id is that?

this issue originally track this: #51 (comment)

from enclave-cc.

can you be more specific on this?

base64 encode /etc/decrypt_config.conf into an env var set by our CcRuntime resource and then then enclave-cc payload installer can decode it into /etc/decrypt_config.conf for the bundle it is installing. With this, no operator modifications are needed.

this issue originally track this: #51 (comment)

Thanks! What is the problem this triggers?

from enclave-cc.

base64 encode /etc/decrypt_config.conf into an env var set by our CcRuntime resource and then then enclave-cc payload installer can decode it into /etc/decrypt_config.conf for the bundle it is installing. With this, no operator modifications are needed.

think we are on same page, that's exactly what I want to say by "operator to set agent config during runtime install" :-) , no change needed in operator logic but only the runtime definition file https://github.com/confidential-containers/enclave-cc/blob/main/tools/packaging/deploy/ccruntime.yaml and runtime deploy script https://github.com/confidential-containers/enclave-cc/blob/main/tools/packaging/deploy/enclave-cc-deploy.sh

Thanks! What is the problem this triggers?

the agent config reading happens too late and the image-rs client can not use the config to instantize, i.e.: the agent config file will not take effective in this case

from enclave-cc.

I'm not sure why ENABLE_SECURITY_VALIDATE is configurable through ENV variable. I mean the behavior of ENABLE_SECURITY_VALIDATE should be mandatory, rather than optional or configurable, unless the image-rs is built as debug mode.

I concur with @jiazhang0 on this, glad the default is check signature.
@hairongchen and @HaokunX-intel - Would it be possible that image-rs first checks if image is signed, if not, perhaps logs something ("Alert - insecure use, image / not signed") and then proceed to download the image.

from enclave-cc.

I'm not sure why ENABLE_SECURITY_VALIDATE is configurable through ENV variable. I mean the behavior of ENABLE_SECURITY_VALIDATE should be mandatory, rather than optional or configurable, unless the image-rs is built as debug mode.

I concur with @jiazhang0 on this, glad the default is check signature. @hairongchen and @HaokunX-intel - Would it be possible that image-rs first checks if image is signed, if not, perhaps logs something ("Alert - insecure use, image / not signed") and then proceed to download the image.

@mkbhanda I agree with the idea proposed in section "What container image signing means for CC" in confidential-containers/documentation#18, that image signing actually means more than just verify the integrity of the image, but also helps the TEE owner to certify a certain image can be pulled into this TEE(control via policy.json) and run it, in this sense, this signature check flag can only be explicitly disable after the workload provider had a clear understanding of the risk.

from enclave-cc.

closed after merged #83

from enclave-cc.