You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hi Atlassian Community:
We are running self hosted pipelines runner in GKE cluster. We need to pull/push docker images from/to "gcr.io" in a pipeline.
In GKE cluster, we use Kubernetes Service Account + GKE workload identity to allow an application (Kubernetes POD) to be able to access GCP services/resources, including logging in to gcr.io. This is a regular and recommended way to authorise applications to access services/resources in GCP (and AWS/Azure) cloud environment, and it's safer than using a static service account key file or credentials.
With Kubernetes Service Account + GKE Workload Identity, we can login to “gcr.io” in the bitbucket-pipelines-runner and docker:dind containers of a POD. But a build container which is started by bitbucket-pipelines-runner runs as docker in docker. The build container couldn’t access the mounted service account token in bitbucket-pipelines-runner container (i.e. “/var/run/secrets/kubernetes.io/serviceaccount”). As the result, we won’t be able to login to gcr.io within the build container and “docker build/pull/push” in a pipeline fails.
If we could have an ability to mount “/var/run/secrets/kubernetes.io/serviceaccount” into the build container, the issue would be solved.
With this ability, we may also pass some environment related variables into the build container by mounting file(s) without defining them in Bitbucket Cloud workspace/repository variables separately.
I raised a feature request (https://jira.atlassian.com/browse/BCLOUD-21738) for this. Not sure what's the process for this feature request being picked up?