KBS: Enable deployment for s390x #436
Conversation
Using initContainers, we can make a previously read-only mount point writable. This allows the test code using the set-policy endpoint to function correctly while optimizing the use of configmap. This commit configures the initContainers for the KBS deployment and adjusts the overlays accordingly. Signed-off-by: Hyounggyu Choi <[email protected]>
There was a problem hiding this comment.
Thanks @BbolroC . The init-container way seems work-able for both configMap and writable. I think also needs reviews from @mkulke
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).
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? |
kbs/config/kubernetes/README.md
Outdated
| @@ -9,7 +9,7 @@ We will see how to deploy KBS (with builtin Attestation Service) on a Kubernetes | |||
| Create a secret that you want to be served using this instance of KBS: | |||
|
|
|||
| ```bash | |||
| echo "This is my super secert" > overlays/key.bin | |||
| echo "This is my super secert" > overlays/$(uname -m)/key.bin | |||
There was a problem hiding this comment.
Should probably fix secert -> secret
There was a problem hiding this comment.
Yep, I will change it. Thanks!
| - command: | ||
| - sh | ||
| - -c | ||
| - cp -r /config/$(dirname $(readlink /config/policy.rego))/* /opa/confidential-containers/kbs/ |
There was a problem hiding this comment.
This doesn't support updates at runtime or provisioning resources, right? Maybe this is fine in the short term.
There was a problem hiding this comment.
No, it is just used for copying any data from a read-only mounting point to a writable one before creating a container. I agree with your opinion. Thanks!
BbolroC
force-pushed
the
enable-kustomize-kbs-for-s390x
branch
from
8a6d0b3 to
39c7191
Compare
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. |
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 Forgot mentioning that a file size for one of the files is larger than 150Mb. |
BbolroC
force-pushed
the
enable-kustomize-kbs-for-s390x
branch
from
39c7191 to
f2ef314
Compare
The following changes enable KBS deployment with a different configuration for s390x:
- Environment variable declaration: SE_SKIP_CERTS_VERIFICATION
- Persist volume/volume claim: required attestation credentials
This commit differentiates the {overlays, nodeport} configuration for KBS deployment
between x86_64 and s390x. It also includes updates to `deploy-kbs.sh`.
Signed-off-by: Hyounggyu Choi <[email protected]>
This commit updates the documentation to include instructions for KBS deployment on s390x. Signed-off-by: Hyounggyu Choi <[email protected]>
BbolroC
force-pushed
the
enable-kustomize-kbs-for-s390x
branch
from
f2ef314 to
0e229a7
Compare
The following changes have been made to enable the KBS deployment for s390x:
/opa/confidential-containers/kbswritable (for both arches, reviving kbs: Revert support for configurable policy #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 [email protected]