Uploaded image for project: 'Openshift sandboxed containers'
  1. Openshift sandboxed containers
  2. KATA-4106

Regression: peer-pods fails to pull images from RH registry

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Medium Medium
    • None
    • None
    • None
    • None
    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • False
    • Bugs and Vulnerability Issues

      Description

      Running a peer-pod that uses an image from registry.redhat.io fails to pull the image.
      This is a regression introduced in OSC 1.10.x, where the image pull mechanism was changed (upstream PR #2232) and the previous auth-json-secret mechanism was dropped.

      Currently, pulling private images (e.g., from registry.redhat.io) requires manual configuration. For a native container-like experience, this should be automated.

      Steps to reproduce

      1. install OSC 1.10.1 with PP enabled
      2. run the following pod

      apiVersion: v1
kind: Pod
metadata:
 name: sleep
spec:
 runtimeClassName: kata-remote
 containers:
   - name: sleeping
     image: registry.redhat.io/ubi9/ubi:latest
     command: ["sleep"]
     args: ["infinity"]

       

      Expected result

      pod will run

      Actual result

       

      2025/08/21 07:07:02 [adaptor/proxy] CreateContainer fails: rpc error: code = Internal desc = failed to pull image registry.redhat.io/ubi9/ubi:latest

Stack backtrace:
   0: anyhow::kind::Adhoc::new
   1: anyhow::__private::format_err.12564
   2: <kata_agent::storage::image_pull_handler::ImagePullHandler as kata_agent::storage::StorageHandler>::create_device::{{closure}}
   3: kata_agent::storage::add_storages::{{closure}}
   4: kata_agent::rpc::AgentService::do_create_container::{{closure}}::{{closure}}.12686
   5: <kata_agent::rpc::AgentService as protocols::agent_ttrpc_async::AgentService>::create_container::{{closure}}
   6: <protocols::agent_ttrpc_async::CreateContainerMethod as ttrpc::asynchronous::utils::MethodHandler>::handler::{{closure}}
   7: ttrpc::asynchronous::server::HandlerContext::handle_msg::{{closure}}
   8: <ttrpc::asynchronous::server::ServerReader as ttrpc::asynchronous::connection::ReaderDelegate>::handle_msg::{{closure}}::{{closure}}
   9: tokio::runtime::task::raw::poll
  10: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  11: tokio::runtime::task::raw::poll
  12: std::sys::backtrace::__rust_begin_short_backtrace
  13: core::ops::function::FnOnce::call_once{{vtable.shim}}
  14: std::sys::pal::unix::thread::thread::new::thread_start
  15: start_thread
  16: __clone3

       

      Impact

      Any kata-remote pod with that uses non-public image will fail to start with the default configuration

      Workaround

      To run peer-pod workloads that use private images (e.g., from registry.redhat.io), configure a ServiceAccount or imagePullSecret with the proper credentials.

      To replicate the native OpenShift pod experience, copy the cluster-wide pull secret into the namespace where your peer-pods workload is deployed:

      NS=<peer-pod namespace>
oc get secret pull-secret -n openshift-config -o yaml | sed "s/namespace: openshift-config/namespace: ${NS}/" | kubectl apply -n "${NS}" -f -

      Then you can either link this secret to the default service account:

      oc secrets link default pull-secret --for=pull -n ${NS}

      or, add to the peer-pod yaml:

      imagePullSecrets: 
 - name: pull-secret

              ssheribe@redhat.com Snir sheriber
              rh-ee-chbutler Chris Butler
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: