-
Story
-
Resolution: Done
-
Normal
-
None
-
None
-
BU Product Work
-
False
-
None
-
False
-
NEW
-
OCPSTRAT-1290 - [GA] Multiarch Tuning Operator
-
x86_64, ppc64le, s390x, aarch64
-
-
-
Multi-Arch Sprint 259, Multi-Arch Sprint 260
Inspection caching is partially implemented and bypassed as in https://issues.redhat.com/browse/MIXEDARCH-328
The cache was disabled in https://github.com/openshift/multiarch-tuning-operator/commit/1679c05e97abe09c94f163fbde91cce46a06d4f5 because it has no eviction policy and can lead to leaking metadata for consumers that shouldn't be able to access a given image's metadata and even pull it.
We need to revert that commit and, probably, change the return type of https://github.com/openshift/multiarch-tuning-operator/blob/1679c05e97abe09c94f163fbde91cce46a06d4f5/pkg/image/cache.go#L48-L54 to be *cacheProxy in order to be able reaching the registryInspector field when instantiating the Facade.
Acceptance criteria:
0. The cache is re-enabled
1. The key being used for the cache is safe/secure: the current/PoC implementation (disabled in 0.9) uses the image reference as key, but this poses a security issue. In fact, if the same image is set for a pod with imagePullSecrets that cannot actually pull that image, we are leaking some metadata about the image (the compatible architectures).
From a functional perspective, let's assume that we have two pods consuming the same image, A and B. Pod A has a pull secret that can access the image, Pod B can't. We expect that (1) the first instance of pod A will populate the cache with the compatible architectures for that image, (2) pod B doesn't get a HIT in the cache and doesn't get any predicate for the compatible architecture as it cannot access the information about the image and also gets into imagePullBackOff, (3) another instance of pod A like a new replica of the deployment owning it, A', gets a cache HIT and populate the predicate without the need of making a request to the registry inspector.
Safe cache key possible implementation
The key of the cache can be computed as the SHA256 Hash of the string cosisting of "imageRef+sortedListOfPodsPullSecretsContent". This will probably include more registries than the required one, but we can consider it safe enough.
This snippet should be exported and put in a function, marshaledImagePullSecrets([][]byte) that can be consumed by both the current method and the cache one. https://github.com/openshift/multiarch-tuning-operator/blob/e1f8406563944d75de8a3207b2f32e0ff8e86de6/pkg/image/inspector.go#L148-L163
In https://github.com/openshift/multiarch-tuning-operator/blob/e1f8406563944d75de8a3207b2f32e0ff8e86de6/pkg/image/inspector.go#L148-L163. instead of using the `imageReference` value as the key for the cache, let's compute the key as sha256(imageReference + marshaledImagePullSecrets(secrets)). (+ is the concatenation operator)
- clones
-
MULTIARCH-4285 Implement cache eviction policy
- Closed