Access GCP Services within Container about cloud-builders HOT 20 CLOSED

Sorry about not updating this - Instead of --link= you should use --network=cloudbuild for the same effect.

from cloud-builders.

@imjasonh

i am trying to generate a JWT token

curl --get --data-urlencode "audience=https://example.com" --data-urlencode "format=full" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity

The above returns a JWT on a compute instance, however, on cloudbuild i get "not found" as a result... matter of fact the above endpoint that you curled returns "not found" to me... it doesn't return the sub-paths

- name: 'gcr.io/cloud-builders/curl'
  id: set-env
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    curl -H "Metadata-Flavor: google" --get --data-urlencode "audience=http://example.com" --data-urlencode "format=full" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity"

running the above config in cloud-build-local gives the same error as running it in cloudbuild itself.

P.S. i created a ticket as suggested to the above tracker (https://issuetracker.google.com/issues/139011732).

from cloud-builders.

This is an unexpected failure, is this repeatable? We have numerous tests that rely on this behavior, which pass successfully, so if you could provide more repro steps that would help us get to the bottom of the issue.

from cloud-builders.

By any chance, are you running a container within a build step? eg

name: 'gcr.io/cloud-builders/docker'
args: ['run', 'gcr.io/$PROJECT_ID/my-container-image']

If so, then currently we don't forward credentials inside automatically. We hope to address this issue at some point. In the mean time you can forward them yourself with --link metadata:metadata.google.internal as one of the args after run.

from cloud-builders.

Yes, it's within a step.

That's fine re adding the link. But it doesn't seem to work - I add this to docker-compose, but no luck.

    external_links:
      - metadata:metadata.google.internal

build-id 31e9c761-4062-40f2-aafa-4115a7fb9511. I can contact support if that's easier? Or leave it if it's really not supported

from cloud-builders.

There is no value in contacting support if you're already contacting us - we're the eng team for container builder. :)

If you fetch http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true directly from inside the step, do you get something that looks like a token?

For instance, this works for me:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args:
  - 'run'
  - '--link=metadata:metadata.google.internal'
  - '--entrypoint=ash'
  - 'alpine'
  - '-c'
  - |
    apk add --update curl
    curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true                                      

from cloud-builders.

It does work with --link, thanks! IMO That's a very acceptable work around, assuming it's documented.

I'm not sure why --link works but not --external-links - not on your team though.

from cloud-builders.

I've done a bit of research, but the difference between external links and normal links is not crystal clear to me. Neither will be necessary in our glorious future, though the feature is currently unscheduled.

from cloud-builders.

Neither will be necessary in our glorious future

🥇

from cloud-builders.

This isn't crucial, so happy to leave it. I think the answer is something to do with this: https://stackoverflow.com/a/39068043/3064736

Do you happen to know what networks are in the current docker setup? I can then connect my container to one and it should find the metadata container through that

from cloud-builders.

The glorious future is when we actually start creating a network :) I'm going to reopen this issue and use it to track this feature.

from cloud-builders.

Does this workaround also apply for the java/mvn image? I have a couple of tests that communicate with other cloud services and it would be very neat to have it all within container builder.

from cloud-builders.

@james-woods This workaround should work for most cases where you run a docker container inside of a build step. Specifically, if the inner container (the one being run inside the build step) is able to access credentialed GCP services when running as a build step (i.e., not inside another build step container), then this workaround will work. (For some build steps, even running on their own they can't access credentialed GCP services, and for these the workaround won't help.)

from cloud-builders.

@bendory - so to clarify, it will not work with the official java/mvn image - as I don't run a docker container there I just execute a command from within a pre-existing one.

from cloud-builders.

The workaround is specifically for this situation:

• You have a container that accesses credentialed GCP services and works fine when used as a build step.
• You are running that container inside another container, and it gets permission errors when run there.

from cloud-builders.

Hi @skelterjohn - is there any update here? The --link=metadata:metadata.google.internal work-around seems to have stopped working a couple months ago (though we turned it off so potentially it's come back recently)

from cloud-builders.

so i am having a hell of a time trying to figure out why the following is not working

curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/

i want to access the identity endpoint but the above just returns a 404 on the docker image... running something simple as

- name: 'gcr.io/cloud-builders/docker'
  id: set-env
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/

I am essentially trying to generate a JWT by hitting the endpoint so i can authenticate to Hashicorp Vault to pull some secrets during cloudbuild step.

curl --get --data-urlencode "audience=https://example.com" --data-urlencode "format=full" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity

from cloud-builders.

@zbutt-muvaki This seems to be a new bug report or feature request, separate from the initial bug report. We also ask that questions/issues with the GCB API service get filed to the public issue tracker at https://issuetracker.google.com/issues/new?component=190802&template=1162743 (if you'd created a new issue you would have been prompted to do this).

That being said, I can explain what's happening. GCB workers spoof the metadata server to inject builder service account credentials and other relevant information. That endpoint is, probably due to oversight, not spoofed by GCB's metadata server.

What information are you trying to ascertain? Hitting that endpoint on a "real" metadata server results in a directory listing of sub-paths that you can hit:

$ curl -H "Metadata-Flavor: google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/
email/
scopes/
token/

Each of these endpoints are correctly spoofed, and return the expected responses about the builder service account.

from cloud-builders.

@zbutt-muvaki @imjasonh im running into the same issue, when i try to hit the metadata server for a http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=myblablablablblabl` i get a 404 inside of cloud build

from cloud-builders.

This GitHub issue tracker is specifically intended for bugs with the officially supported builder images.

To report an issue with the Google Cloud Build service, please report it to our public issue tracker at https://issuetracker.google.com/issues/new?component=190802&template=1162743

from cloud-builders.