Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
[feature] Support other gcp project's gcr images to be pulled by service account with workload identity
See original GitHub issueFeature Area
/area backend
What feature would you like to see?
Current workload identity supports multiple project for calling normal APIs, but we cannot pull images on other project’s container registry even if the google service account has enough storage permissions (ErrImagePull occurs).
I don’t know who can handle better (GCP’s backend or Kubeflow Pipelines), but I confirmed that we can pull images after calling gcloud configure-docker.
What is the use case or pain point?
With this supported, we can easily call other GCP project’s API on Kubeflow Pipelines easily.
Is there a workaround currently?
We can use normal kubernetes secret for imagePullSecret.
Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
In my organization we grant permission to nodepoolSA. I suppose docker pull secrets might work as well. However default-editor/pipeline-runner does not pull images and hence granting permission to it will not work.
A GKE nodepool has a VM service account. This is used to pull images. You need to grant storage permission to this SA.