Help us avoid credential leak into containers - Use a default credential file path

[thclark]

TL;DR

Use google's usual default path (google_credentials.json) for generated application credentials, or alternatively allow us to specify the path of the credentials file that gets created.

This will help us avoid by default a significant vulnerability that it's easy to introduce by mistake: baking credentials into images for all to see.

Detailed design

Lets say I use this action to do a typical thing: build a container and push it to GCR:

name: build_container_and_push_to_gcr

on:
  workflow_dispatch:

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Authenticate with GCP Workload Identity
        id: auth
        uses: google-github-actions/auth@v0.5.0
        with:
          create_credentials_file: true
          workload_identity_provider: REDACTED
          service_account: REDACTED

      - name: Setup gcloud
        uses: 'google-github-actions/setup-gcloud@v0'

      - name: Configure Docker to push images to GCP
        run: gcloud auth configure-docker

      - name: Build
        uses: docker/build-push-action@v2
        with:
          context: .
          file: Dockerfile
          tags: this-contains:the-account-credentials
          
      - name: Other stuff
         run: echo "Do testing stuff which might require the credentials file"

The auth step creates a credentials file with a randomised name - like /home/runner/work/me/myrepo/4c33e43f60be11e1a7b5d5f4.

The problem occurs when Dockerfile contains the following extremely common line:

COPY . .

If you're like me, you'll have a .dockerignore file will include something like:

# NEVER bake in environment variables or credentials
.env
.env*
google_credentials.json

But, because in this case the credentials file name cannot be known a priori, the .dockerignore can't be configured not to copy it in.

Proposed solution

• Revert to a predictable file name, or make user specify as a required argument
• [Optional, but nice] Check for presence of .dockerignore and if it doesn't contain the file then warn the user
• [Optional, but nice] Add a boolean--update-dockerignore option, true by default, that creates or updates a .dockerignore file with the credentials file name

A possible workaround

As one possible workaround, I'd have to introduce a step something like

    - name: Prevent secret from getting into container
      # WARNING UNTESTED!!!
      run: touch .dockerignore && echo ${${{ steps.auth.outputs.credentials_file_path }}##*/} >> .dockerignore

    - name: Now its safe to build
      #...

Additional information

I also think it's a bit more intuitive for it to end up in google_credentials.json, the location given in most of google's tutorials on application credentials.

[sethvargo]

Hi @thclark - thank you for opening an issue.

Use google's usual default path (google_credentials.json) for generated application credentials, or alternatively allow us to specify the path of the credentials file that gets created.

This is not a default that I'm aware of. gcloud definitely doesn't use that naming, and I haven't seen it anywhere else. It's not mentioned anywhere on cloud.google.com.

---

The credentials are checked out into the workspace because that's the only way to ensure they are available for Docker-based actions to authenticate seamlessly. The auth action also automatically removes the credential at the end of the job via a post step, so the credential will never persist between jobs. I described this in more detail in #109 (comment).

I think the most elegant solution is to re-arrange your steps. You don't need authentication to build the image, so:

1. Build
2. Auth
3. Push

Additionally, if you only need to push to GCR/GAR, you don't need to install and configure gcloud. You can authenticate using an access token generated from the auth action, and then set create_credentials_file to false to prevent creation entirely, as shown in #104 (comment).

Alternatively, you could do as suggested and add ${{ steps.auth.outputs.credentials_file_path }} to your dockerignore.

I'm opposed to any tight coupling of this action to anything related to Docker.

[bharathkkb]

@sethvargo we had a few issues about pushing to GAR/GCR (#104 (comment), #50 (comment)) should we have an example that showcases this?

[sethvargo]

@bharathkkb created a new issue to track that.

[thclark]

If that example were to cover this use case and note it, that'd be a good step to addressing this - people are most likely to piece together steps off the net (like I did) unless they see a full example.

I'm working on mapping application default credentials into my test container, avoiding the need for creating the creds file, which I think might be a more elegant solution overall (inspired by this very useful article). When I get it working (or don't and end up with a different pattern) I'll something in #126.

And thanks @sethvargo for your help. I now realise the "default" was from years ago when the json service account keys first came out and they were downloaded from the console with that filename. Now they're downloaded with a unique filename - google must have realised the likely vulnerability from a uniformly named credentials file that can be accidentally committed.

[jsiebens]

Hi,

I'm facing a problem that is somehow related to this issue.
I'm trying to use goreleaser to build and publish artifacts to GCS and GCR, but goreleaser will not run because the repo is in a dirty state after the gcp credential file is created.
If I'm able to configure e.g. a subdirectory where the credential file is generated, I can add that to the .gitignore file and goreleaser should ignore the generated file when validating for a dirty state.

ref: https://goreleaser.com/errors/dirty/

[thclark]

Thanks @sethvargo that makes things way simpler :)

[sethvargo]

I still need to cut v0.6.0 - want to get a few other changes in.