Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: support export auth export with envvar for backwards compat #426

Merged
merged 10 commits into from
Dec 22, 2021

Conversation

bharathkkb
Copy link
Contributor

@bharathkkb bharathkkb requested a review from a team as a code owner December 7, 2021 00:25
.github/workflows/setup-gcloud-it.yml Outdated Show resolved Hide resolved
.github/workflows/setup-gcloud-it.yml Outdated Show resolved Hide resolved
process.env.GOOGLE_GHA_CREDS_PATH,
'utf8',
);
serviceAccountKeyObj = parseServiceAccountKey(cPath);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will work, because the export from auth could be a WIF cred file, which isn't a "service account key"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I refactored the logic a bit based on what we discussed yesterday and added some test cases for more scenarios. I also added a warning to help users migrating that export_creds is not necessary when using setup-gcloud in conjunction with auth.

credsPath = process.env.GOOGLE_GHA_CREDS_PATH;
// User is likely using google-github-actions/auth for auth followed by setup-gcloud with export_default_credentials.
// This is unnecessary as auth already exports credentials.
core.warning(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setup-gcloud also exports GOOGLE_GHA_CREDS_PATH (maybe we should remove that?), so I think you'd hit this block with back-to-back export_default_credentials for two setup-gcloud uses.

We should add an integration test to make sure back-to-back setup-gcloud works and uses the correct auth:

- uses: setup-gcloud
  with:
    credentials: cred1

- run: gcloud auth list | gregp 'cred1email'

- uses: setup-gcloud
  with:
    credentials: cred2

- run: gcloud auth list | gregp 'cred2email'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'll be fine because it'll fall into the first case of this conditional, but it gets weird if the user does:

- uses: setup-gcloud
  with:
    credentials: cred1

- run: gcloud auth list | gregp 'cred1email'

# I think this will throw the warning
- uses: setup-gcloud

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the first case would be fine

For

- uses: setup-gcloud
  with:
    credentials: cred1
    
- uses: setup-gcloud

since user is not specifying explicit creds, it is no op.
Using something else other than GOOGLE_GHA_CREDS_PATH for cleanup in setup-gcloud is also feasible.

credsPath,
JSON.stringify(serviceAccountKeyObj, null, 2), // Print to file as string w/ indents
);
core.exportVariable('GCLOUD_PROJECT', serviceAccountKeyObj.project_id);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should only set the project ID here if the project_id input wasn't given above. If the user explicitly set a project_id, we should prefer that over the SA's project. Probably be good to compare the project IDs and throw a warning if they are different too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done and added a warning. In the earlier flow we were setting GCLOUD_PROJECT to serviceAccountKeyObj.project_id and then re exporting GCLOUD_PROJECT as projectID if set. Hopefully the newer flow is clearer.

src/setup-gcloud.ts Show resolved Hide resolved
src/setup-gcloud.ts Show resolved Hide resolved
@bharathkkb bharathkkb merged commit aaf4f27 into master Dec 22, 2021
@bharathkkb bharathkkb deleted the fix-export branch December 22, 2021 17:10
@kaominghsu
Copy link

Hello,
I think the private_key of service_account passes through base64, resulting in insufficient length

@sethvargo
Copy link
Member

Hi @kaominghsu - if you're having an issue, please open a new GitHub issue and complete the issue template so we have the necessary information to debug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Authenticating via Service Account Key JSON does not work
3 participants