Open tarun360 opened 1 year ago
This wasn't required previously with podman.
If this is a regression please specify the last working version?
The above results are with version 4.4.2
.
Before this we were using version 4.3.0
, on top of which we added the patch for encryption-decryption (because this patch was only added in v4.4.0 and wasn't available in v4.3.0). With this the decryption while pulling of image was happening automatically.
Since version v4.4.2 now has the encryption-decryption feature, we now wanted to use this version, but with this we are facing the above mentioned bug.
@mtrmac PTAL
I think I found the problem. So consider two functions f1:
func DecryptConfig(decryptionKeys []string) (*encconfig.DecryptConfig, error) {
var decryptConfig *encconfig.DecryptConfig
if len(decryptionKeys) > 0 {
// decryption
dcc, err := enchelpers.CreateCryptoConfig([]string{}, decryptionKeys)
if err != nil {
return nil, fmt.Errorf("invalid decryption keys: %w", err)
}
cc := encconfig.CombineCryptoConfigs([]encconfig.CryptoConfig{dcc})
decryptConfig = cc.DecryptConfig
}
return decryptConfig, nil
}
f2:
func DecryptConfig(decryptionKeys []string) (*encconfig.DecryptConfig, error) {
decryptConfig := &encconfig.DecryptConfig{}
if len(decryptionKeys) > 0 {
// decryption
dcc, err := enchelpers.CreateCryptoConfig([]string{}, decryptionKeys)
if err != nil {
return nil, fmt.Errorf("invalid decryption keys: %w", err)
}
cc := encconfig.CombineCryptoConfigs([]encconfig.CryptoConfig{dcc})
decryptConfig = cc.DecryptConfig
}
return decryptConfig, nil
}
The only difference is in 2nd line of code.
f1 is used podman. f2 is used in buildah.
This small difference in these functions is cause of the discrepancy between podman & buildah's behaviour w.r.t decrypting image.
Explanation why the difference between f1 and f2 matters:
If --decryption-key flag is not passed, f1 returns nil while f2 returns decryptConfig object with empty string for decryption keys.
Now ultimately if you trace a lot of function calls, you reach at this line of code. Here:
If decryptConfig is nil (as is in case of f1 => podman), decryption is not even tried.
If decryptConfig is not nil (as is in case of f2 => buildah), then even if decryption-key string is empty, because of this init function, it still loads key-provider-config and decrypts the image successfully.
This also means we can pass just --decryption-key provider:
to make sure decryptConfig is not nil (no need to specify simplecrypt
), and the decryption will work.
Before this we were using version 4.3.0, on top of which we added the patch for https://github.com/containers/podman/pull/16329 (because this patch was only added in v4.4.0 and wasn't available in v4.3.0). With this the decryption while pulling of image was happening automatically.
This is incorrect from my side. We merged the above branch into v4.3.0 before this review comment by @mtrmac was resolved. So in our internal podman patch we were using f2 and not f1, and hence decryption while pulling of image was happening automatically.
- If decryptConfig is nil (as is in case of f1 => podman), decryption is not even tried.
Thanks.
I think the above is the correct behavior: it must be possible to copy an image (e.g. using skopeo copy
) just as a blob without decrypting it, so enabling decryption on every single copy is undesirable. Indiscriminately enabling decryption also has other side effects for generic copies, like preventing layer reuse.
(I’m also fairly suspicious of external environment, like environment variables, silently affecting operations — especially in a security context — although I recognize it’s sometimes very practical.)
Admittedly, for a podman pull
or buildah from
, unlike skopeo copy
, there is no option to not decrypt: the encrypted image can’t be stored in local storage, so the only question is whether we can decrypt silently or whether we require an explicit user instruction. Still, I think it’s safer to be explicit.
So, if that config file can be used by passing a valid --decryption-key
parameter, I think that’s what should happen. I have filed https://github.com/containers/buildah/pull/4745 to make Buildah behave similarly.
so the only question is whether we can decrypt silently or whether we require an explicit user instruction. Still, I think it’s safer to be explicit.
So, if that config file can be used by passing a valid --decryption-key parameter, I think that’s what should happen.
Even if we use function f1
, you can just pass --decryption-key provider:
which will make sure that decryptConfig
is not nil
(we don't need to pass --decryption-key provider:simplecrypt
) and the decryption will be done successfully. This is more specific than not providing --decryption-key
parameter at all, but still its not exactly being specific I think?
I don’t know how much of that is an intentional feature of the encryption library, and how much is an unintended implementation artifact; AFAICS https://github.com/containers/ocicrypt/blob/main/docs/keyprovider.md doesn’t say and I don’t know of any other documentation.
@lumjjb WDYT?
as i recall, the intention is to be able to let the implementation choose and the use of nil was a mechanism to display intent. That probably was not documented well here, apologies.
Also + @stefanberger who may also have context/comments.
I think the issue with the keyprovider 'technology' is that the keyprovider cannot easily be determined if one was to have several ones installed. We can match gpg encryption scheme to gpg keys, jwe encryption scheme to jwk keys etc. but this is not so easily possible with the generic keyprovider.
A friendly reminder that this issue had no activity for 30 days.
@lumjjb @mtrmac What should we do with this issue?
@rhatdan This is your own https://github.com/containers/buildah/pull/4746 + a Podman change to use that shared implementation.
Issue Description
Podman pull not automatically decrypting the image while pulling the images unless I explicitly provide the provider as flag
--decryption-key provider:simplecrypt
. This wasn't required previously with podman.With buildah & skopeo decryption still is happening automatically without explicitly specifying the provider using flag
--decryption-key provider:simplecrypt
Steps to reproduce the issue
Steps to reproduce the issue
Build a sample golang application/binary -> https://github.com/lumjjb/simple-ocicrypt-keyprovider
Configure the
ocirypt.conf
like belowPull an image
$ podman pull docker.io/library/alpine:latest
Encrypt this image:
Decrypt the image without specifying the provider (fails, this is the bug):
Decrypt the image with specifying the provider explicitly (works):
Decrypt the image without specifying the provider using buildah (works):
Describe the results you received
This is failing:
Describe the results you expected
I would expect the command
OCICRYPT_KEYPROVIDER_CONFIG=/path/to/ocicrypt.conf podman pull oci-archive:encrypted
to work.podman info output
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
No
Additional environment details
No response
Additional information
No response