Enable WASM Workloads with Encrypted Layer Support #1271
Conversation
rodneyosodo
force-pushed
the
enable-wasm-workloads
branch
2 times, most recently
from
3c906b0 to
729be3a
Compare
fitzthum
left a comment
fitzthum
left a comment
There was a problem hiding this comment.
Looks cool.
Can you expand the commit message a little bit.
Also, are there any testing images available for this? I guess it might be tricky since it is encrypted, but ideally we would have coverage here.
Anyway, I will spin the CI. Welcome
|
Hello @fitzthum I found out the issue might also be related to https://github.com/containers/skopeo I have submitted these changes containers/container-libs#596 thereafter I will upstream them to containers/skopeo#2791. I noticed we are using a specific version of |
Without diving deep into this - skopeo is now only used in image encryption, so is it possible for you to generate a test image with new skopeo, but only decrypt with image-rs? A unit test might help |
|
Yeah as @Xynnn007 mentions, skopeo is not a direct dependency for us. It shows up a few places in the repo because we use it to make test images, but we don't have a particular version requirement. To make sure that image-rs can unpack an image that corresponds to a particular version of skopeo (and whatever else), it's best to provide an image that we can try unpacking in a unit test. |
rodneyosodo
force-pushed
the
enable-wasm-workloads
branch
from
729be3a to
1305c61
Compare
rodneyosodo
changed the title
rodneyosodo
force-pushed
the
enable-wasm-workloads
branch
from
1305c61 to
edcb6b9
Compare
mkulke
left a comment
mkulke
left a comment
There was a problem hiding this comment.
thanks!
some documentation would be good, e.g. instructions on how to create an image with encrypted wasm layers.
there are also some semantics that would need to be explained (e.g. scheme.starts_with(".provider")) if those are newly introduced it would be good to provide a rationale in the PR description and cover the new behaviour in unit tests
This crate is a port of the ocicrypt golang project, is there similar logic/prior art in the golang ocicrypt library for encrypted wasm layer. We probably want to keep close to that.
image-rs/src/stream/mod.rs
Outdated
| match tokio::io::copy(&mut hash_reader, &mut wasm_file).await { | ||
| Ok(_) => Ok(hash_reader.hasher.digest_finalize()), | ||
| Err(e) => { | ||
| tokio::fs::remove_dir_all(destination).await.ok(); | ||
| Err(StreamError::FailedToRollBack { source: e }) | ||
| } | ||
| } |
There was a problem hiding this comment.
| match tokio::io::copy(&mut hash_reader, &mut wasm_file).await { | |
| Ok(_) => Ok(hash_reader.hasher.digest_finalize()), | |
| Err(e) => { | |
| tokio::fs::remove_dir_all(destination).await.ok(); | |
| Err(StreamError::FailedToRollBack { source: e }) | |
| } | |
| } | |
| let Ok(_) = tokio::io::copy(&mut hash_reader, &mut wasm_file).await else { | |
| tokio::fs::remove_dir_all(destination).await.ok(); | |
| return Err(StreamError::FailedToRollBack { source: e }); | |
| } | |
| Ok(hash_reader.hasher.digest_finalize()) |
| // If the key is not 32 bytes (256-bit AES key), try base64 decoding | ||
| // Some KBS implementations return base64-encoded keys or text with newlines | ||
| if key.len() != 32 { | ||
| // First, try to interpret as UTF-8 string and trim whitespace | ||
| let key_str = String::from_utf8_lossy(&key); | ||
| let trimmed = key_str.trim(); | ||
| let engine = base64::engine::general_purpose::STANDARD; | ||
| let decoded = engine.decode(trimmed.as_bytes())?; |
There was a problem hiding this comment.
this kind of ambiguity is suprising. which KBS implementations are we talking about? do we perform similar heuristics for other layer decryptions?
Signed-off-by: Rodney Osodo <[email protected]>
Signed-off-by: Rodney Osodo <[email protected]>
rodneyosodo
force-pushed
the
enable-wasm-workloads
branch
from
edcb6b9 to
ad9c6ab
Compare
Signed-off-by: Rodney Osodo <[email protected]>
|
Hello @mkulke
I have submitted this PR containers/ocicrypt#126 with respect to this |
Signed-off-by: Rodney Osodo <[email protected]>
- Modified set_perms_ownerships() to skip ownership changes when not root - Added graceful handling for mknod() and xattr operations requiring privileges - Updated test_unpack to conditionally check ownership based on root status - Added is_root() helper and runtime checks for integration tests - Fixed async_handle_layer to properly set decoder field in LayerMeta - Updated test_async_handle_layer to reflect current empty diff_id behavior - All 72 tests now pass without requiring sudo or ignore flags Signed-off-by: Rodney Osodo <[email protected]>
rodneyosodo
force-pushed
the
enable-wasm-workloads
branch
from
f1c6062 to
33c412c
Compare
4 participants
What does the PR do?
This PR adds support for encrypted WebAssembly (WASM) workloads by implementing the encrypted WASM media type (
application/vnd.wasm.content.layer.v1+wasm+encrypted) and enhancing the keyprovider service with full decryption capabilities. The implementation includes a new cryptographic module supporting AES-256-GCM and AES-256-CTR encryption algorithms, and completes the previously unimplemented UnWrapKey gRPC method that retrieves Key Encryption Keys (KEK) from KBS and performs layer key unwrapping.The changes enable pulling encrypted WASM layers from OCI registries with proper stream processing that writes WASM binary modules directly to disk (as
module.wasm) rather than unpacking them as tar archives. The image-rs components have been updated to recognize and handle encrypted WASM media types throughout the decryption, decoding, and pulling workflows, with support for SHA-256/SHA-512 digest verification.Reference