Uploaded image for project: 'Multiple Architecture Enablement'
  1. Multiple Architecture Enablement
  2. MULTIARCH-4782

Reactivate cache and use a safe key

XMLWordPrintable

    • 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)

       

            tzivkovi@redhat.com Tori Zivkovic
            rhn-support-adistefa Alessandro Di Stefano
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: