Closed noamz1 closed 9 months ago
What keyprovider are you using so I can recreate the issue?
non, the config is empty.. just using the keys in /etc/containerd/ocicrypt/keys
the initial encryption was done with skopeo
Can you provide a reproducer?
I will try to modify the testLocalKeys test case. Maybe it has something to do with the --decryption-keys-path versus previously resolved issue where keys were passed via the command line.
Can you provide a reproducer?
Sure, as in commands I've used? Or encrypted image and key pair?
Sure, as in commands I've used? Or encrypted image and key pair?
Let me come back to you once I tried modifying the test case.
At this point it would be good if you showed as much of the command line commands as possible to be able to reproduce it. I have been running onto some other issues...
Honestly the only think I did in the command line was encrypting the image with skopeo and redeploying my pod(kubectl delete and apply pod.yaml)
Honestly the only think I did in the command line was encrypting the image with skopeo and redeploying my pod(kubectl delete and apply pod.yaml)
The problem is likely that once an image has been decrypted there is no need to decrypt it again. Only when it is decrypted then the keys in the filesystem would be read by ctd-decode and ctd-decode would find that the right key is missing. ctr-enc
does a lot of the decryption work and authorization checks on the client side and I don't know how this translates to kubernetes instrumentation before it calls to start a container via containerd, because containerd won't check.
Hmm I see.. is there any way I can force decryption? The image I present on my yaml is for sure the encrypted one
Hmm I see.. is there any way I can force decryption? The image I present on my yaml is for sure the encrypted one
I do not think that you can force it. The only way would be to have all containers that use the image terminated and then clean the decrypted image from the local layer repository that containerd maintains.
If I switch to a key provider instead of serving the key from a directory, would the outcome be the same?
If I switch to a key provider instead of serving the key from a directory, would the outcome be the same?
I would not expect it to be different since also in this case the image would have been decrypted and the decrypted image will then be used.
i see.. thank you stefan!
hello, im reffering to this closed issue: https://github.com/containerd/imgcrypt/issues/69 the problem is pretty much the same for me with version 1.1.7. my working environment is this: imgcrypt 1.1.7 k3s v1.22 contrainerd v1.6.12 ubuntu 20.04.5 x86_64(same for image architecture)
containerd config.toml
[plugins."io.containerd.grpc.v1.cri".image_decryption] key_model = "node"
[stream_processors] [stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"] accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"] returns = "application/vnd.oci.image.layer.v1.tar+gzip" path = "ctd-decoder" args = ["--decryption-keys-path", "/etc/containerd/ocicrypt/keys"] env= ["OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf"] [stream_processors."io.containerd.ocicrypt.decoder.v1.tar"] accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"] returns = "application/vnd.oci.image.layer.v1.tar" path = "ctd-decoder" args = ["--decryption-keys-path", "/etc/containerd/ocicrypt/keys"] env= ["OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf"]
to explain the issue, im spinning up an encrypted image while providing the key in the written dir(/etc/containerd/ocicrypt/keys), container spins up successfully but when i remove the key from the directory and try to deploy again, i get no error regarding missing key.
ill be happy to provide any more needed information.