Closed BbolroC closed 3 days ago
why do we need to add a persistent volume? could we just mount the configmap into the init-container (read-only) and copy the file to the (writable) container storage?
Do you see any cons for using the PV? Why I chose the PV is that I just don't want to open any credentials used for a SE verifier to upstream. For me, a PV is the easiest and simplest way of encapsulating those data for kustomize.
why do we need to add a persistent volume? could we just mount the configmap into the init-container (read-only) and copy the file to the (writable) container storage?
Do you see any cons for using the PV? Why I chose the PV is that I just don't want to open any credentials used for a SE verifier to upstream. For me, a PV is the easiest and simplest way of encapsulating those data for kustomize.
why not use the kustomize secret generator?
A question from my side is why not we marked policy as volume rather than configMap. What if a stateful volume? In this way we can probably store the policy in front of time (even for DBs).
I'm not sure what the original idea behind the policy configuration was. We might be able to improve the configuration later after some investigation. Thanks.
why not use the kustomize secret generator?
The configuration is specific to s390x, and a way of configuring the credentials via PV aligns with the documentation at https://github.com/confidential-containers/trustee/tree/main/attestation-service/verifier/src/se. This means that once a user has prepared the credentials following the documentation, they can simply export IBM_SE_CREDS_DIR
to point to the root directory of the credentials.
Forgot mentioning that a file size for one of the files is larger than 150Mb.
The following changes have been made to enable the KBS deployment for s390x:
/opa/confidential-containers/kbs
writable (for both arches, reviving https://github.com/confidential-containers/trustee/pull/431)Detailed explanations can be found in each commit message. Verification was performed on a test machine for each platform.
Signed-off-by: Hyounggyu Choi Hyounggyu.Choi@ibm.com