search

1Password / shell-plugins

Seamless authentication for every tool in your terminal.
https://developer.1password.com/docs/cli/shell-plugins/
MIT License
505 stars 162 forks source link

New plugin: Google Cloud Platform #148

Open caraar12345 opened 1 year ago

caraar12345 commented 1 year ago

Platform or tool

Google Cloud Platform (GCP)

Relevant links

Goal or desired behavior

Contribution

Additional information

I'd be willing to build it myself, but I am struggling to work anything out about whether gcloud supports any kind of external authentication file/variable etc. So any ideas anyone can suggest would be greatly appreciated!

SimonBarendse commented 1 year ago

Hi Aaron, thank you for offering to build a GCP plugin! That will make for a great addition! :raised_hands:

As for gcloud supporting file or envvar, I'm seeing file support mentioned here: https://cloud.google.com/sdk/docs/authorizing#authorize_with_a_service_account, by using --cred-file flag.

You could use the MySQL plugin as an example of a plugin that's provisioning a temporary file: https://github.com/1Password/shell-plugins/blob/9ddb7e3919d0c551cb5033258c702c6cbe2bc89a/plugins/mysql/database_credentials.go#L46

williamhpark commented 1 year ago

Hi Aaron, how's progress coming along for the GCP plugin? I did some research into implementing the GCP plugin myself and if you haven't started on the implementation, I was wondering if you would be okay with me picking up the issue?

caraar12345 commented 1 year ago

Hey, I’ll admit I completely forgot about it so please do feel free to!

On Wed, 22 Feb 2023 at 15:38, William Park @.***> wrote:

Hi Aaron, how's progress coming along for the GCP plugin? I did some research into implementing the GCP plugin myself and if you haven't started on the implementation, I was wondering if you would be okay with me picking up the issue?

— Reply to this email directly, view it on GitHub https://github.com/1Password/shell-plugins/issues/148#issuecomment-1440272244, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOYOFDQ75ORQI5AANF33QDWYYXGJANCNFSM6AAAAAAT5YTD7I . You are receiving this because you were assigned.Message ID: @.***>

carhartl commented 1 year ago

@williamhpark Since you‘ve unassigned yourself, may I take this over?

williamhpark commented 1 year ago

@williamhpark Since you‘ve unassigned yourself, may I take this over?

Hey @carhartl, yes feel free! I did some research but I couldn't get to the implementation stage as I got stuck in a few places. I'll just leave some information that I gathered while I was investigating, hope it can be of use to you.

gcloud uses Google OAuth to authenticate users to the CLI. When gcloud auth login is run, authenticated account data is added to two files at ~/.config/gcloud: credentials.db and access_tokens.db.

For the importer, I was thinking of two potential options:

  1. The credentials.db file could be used as part of a file importer, where the imported fields would be client_id, client_secret, and refresh_token. However, if these are the fields that are being used, what if the user wants to import manually instead? If there's no way to easily find the client_id, client_secret, and refresh_token for a Google account (e.g. in a management console), this strategy is probably not ideal.
  2. Import the Google account email and password. Then, somehow determine the client_id, client_secret, and refresh_token using the email-password pair when provisioning. I tried to find a Google SDK that would allow me to do this but was unsuccessful. Might just require some more digging! This strategy is probably closer to ideal.

For provisioning the credentials, I wasn't able to determine whether credentials.db or access_tokens.db, or both, are necessary when authenticating the gcloud CLI. If a temporary file provisioner is implemented, would temporary files need to be created for both? This was something I got stuck on.

It should be useful to know that an access token is required for authentication, and you can generate it using the client_id, client_secret, and refresh_token by making a POST request to https://www.googleapis.com/oauth2/v4/token. You can check out this Stack Overflow post for more details.

tiagovrtr commented 1 year ago

@williamhpark Since you‘ve unassigned yourself, may I take this over?

Hey @carhartl, yes feel free! I did some research but I couldn't get to the implementation stage as I got stuck in a few places. I'll just leave some information that I gathered while I was investigating, hope it can be of use to you.

gcloud uses Google OAuth to authenticate users to the CLI. When gcloud auth login is run, authenticated account data is added to two files at ~/.config/gcloud: credentials.db and access_tokens.db.

For the importer, I was thinking of two potential options:

  1. The credentials.db file could be used as part of a file importer, where the imported fields would be client_id, client_secret, and refresh_token. However, if these are the fields that are being used, what if the user wants to import manually instead? If there's no way to easily find the client_id, client_secret, and refresh_token for a Google account (e.g. in a management console), this strategy is probably not ideal.
  2. Import the Google account email and password. Then, somehow determine the client_id, client_secret, and refresh_token using the email-password pair when provisioning. I tried to find a Google SDK that would allow me to do this but was unsuccessful. Might just require some more digging! This strategy is probably closer to ideal.

For provisioning the credentials, I wasn't able to determine whether credentials.db or access_tokens.db, or both, are necessary when authenticating the gcloud CLI. If a temporary file provisioner is implemented, would temporary files need to be created for both? This was something I got stuck on.

It should be useful to know that an access token is required for authentication, and you can generate it using the client_id, client_secret, and refresh_token by making a POST request to https://www.googleapis.com/oauth2/v4/token. You can check out this Stack Overflow post for more details.

It might be helpful to use gcloud auth application-default login as it generates a credentials file that can be used by third-party apps to connect to Google Cloud, in the same format used by service accounts in GCP services

tiagovrtr commented 5 months ago

@williamhpark Since you‘ve unassigned yourself, may I take this over?

Hey @carhartl, yes feel free! I did some research but I couldn't get to the implementation stage as I got stuck in a few places. I'll just leave some information that I gathered while I was investigating, hope it can be of use to you.

gcloud uses Google OAuth to authenticate users to the CLI. When gcloud auth login is run, authenticated account data is added to two files at ~/.config/gcloud: credentials.db and access_tokens.db.

For the importer, I was thinking of two potential options:

  1. The credentials.db file could be used as part of a file importer, where the imported fields would be client_id, client_secret, and refresh_token. However, if these are the fields that are being used, what if the user wants to import manually instead? If there's no way to easily find the client_id, client_secret, and refresh_token for a Google account (e.g. in a management console), this strategy is probably not ideal.
  2. Import the Google account email and password. Then, somehow determine the client_id, client_secret, and refresh_token using the email-password pair when provisioning. I tried to find a Google SDK that would allow me to do this but was unsuccessful. Might just require some more digging! This strategy is probably closer to ideal.

For provisioning the credentials, I wasn't able to determine whether credentials.db or access_tokens.db, or both, are necessary when authenticating the gcloud CLI. If a temporary file provisioner is implemented, would temporary files need to be created for both? This was something I got stuck on.

It should be useful to know that an access token is required for authentication, and you can generate it using the client_id, client_secret, and refresh_token by making a POST request to https://www.googleapis.com/oauth2/v4/token. You can check out this Stack Overflow post for more details.

@bobidle, any ideas for this? it would be great to have this!