Feature: Automate integration into lifecycle of GCP Commands

[comp615]

Apologies as I'm trying to navigate using pybritive and it's been a little rocky. I'm trying to script something like a setup script for our environment where users read a bunch of secrets from GCP requiring a profile checkout, and then check back in.

Currently, my understanding of the flow is:

1. pybritive checkout " -t -m gcloudauth
2. pipe the result of that to sh to active the service account
3. run gcloud commands
4. pybritive checkin " -m gcloudauth
5. grep out the service account name and gcloud auth revoke <SA> to reset the gcloud environment

I'd love to make two requests that I know might be a little hard, but would greatly complement this user flow:

1. deeper integration with gcloudauth. Piping the setup command is semi-trivial, but it seems like on the backend, checkin should provide the cleanup command
   a) alternatively, it'd be great if the checkout command and checkin command automatically handled resetting the default account to the user's local default (since otherwise we have to remember and manage that). In short, pybritive should be a wrapper around running some commands where it temporarily enchances gcloud, and then at the end resets and cleans up

2. pybritive clear gcloud-auth-key-files should accept a -t command, otherwise it just throws Error: No tenants found in /Users/charlie.croom/.britive/pybritive.config. Cannot continue.. If I can specify -t in all the other commands, it should work here (also I'm not sure why that prevents cleaning up local files anyways)

Thanks for reading :) A little sad the JS library is going away since that could have been easier to integrate into our JS scripts...but I know y'all are probably just trying to make it work. Appreciate ya!

[twratl]

Thanks for providing this feedback. We will dig into this and come back with some thoughts and timeline.

Most of the features in Britive are customer driven so we truly appreciate the feedback and suggestions.

[twratl]

@comp615, I have reviewed item 2 and cannot reproduce this. As this is a fully local command the --tenant/-t flag is not required here. Perhaps this is just a version issue? Do you see the issue if you upgrade to v1.6.1 via pip install pybritive --upgrade?

Still checking on item 1 but it does sound reasonable that we should support this. There is already precedent for executing othergcloud CLI commands for the pybritive ssh command.

[twratl]

@comp615 how do you envision we obtain the "user's local default" account when resetting the active account for gcloud? There could be scenarios where multiple GCP profiles are checked out at the same time so taking the existing configuration at checkout and resetting back to that may not always make sense. I am thinking a config parameter for GCP which would indicate the default account to reset to upon checkin of a GCP programmatic profile. Thoughts?

[twratl]

A new release candidate has been published to address the 2 items discussed above.

pip install pybritive==1.7.0rc2

Note that you must specify the version as release candidates will not "auto-install".

To use the new feature that auto sets and unsets the gcloud account first please run the below command.

pybritive configure update gcp gcloud_default_account "<account>"

Then when checking out...

pybritive checkout "<profile>" -m gcloudauthexec

When checking in the --mode/-m flag is not required or expected. The check in process will discover if the profile was checked out with mode gcloudauthexec and reset the gcloud account back to whatever is configured, if something is configured.

pybritive checkin "profile"

[comp615]

Hi! Sorry I missed this thread, I can't figure out why...but my apologies,

Confirming that issue number 2 with the tenants is fixed in the new version. Thanks.

I tried out the number 1 workflow here, and a few notes:

I tried without setting gcloud_default_account... as you noted, this does not set my account as the default again. Potentially there's no state kept by britive, but as you mentioned the checkin was able to discover the method of checkout...I assume it might be able to note what the default gcloud profile was before it sets it. Would just make things a little more convenient:
gcloud config list account --format "value(core.account)"
But otherwise worked as promised

(I did need to use -t on checkin as well, probably expected)

Everything else seemed pretty straightforward and worked as I expected. I think this is a VERY nice change for scripting. To be honest, I ended up talking with another engineer who said they just use -c for everything (largely to avoid this hassle). With this change, I think it becomes almost as easy as doing -c for changes which gives a lot more flexibility and gives the programatic checkout option more potential

[twratl]

v1.7.0 is in QA testing now and will be released soon. I will further review the gcloud config list account --format "value(core.account)" for the next release. Perhaps a setting on the gcp pybritive config which says "revert to what it was before" instead of using a static value for the account to revert back to.

[twratl]

This has been released in v1.7.0, which is now available. Will leave this issue open so we can continue to iterate on features for this.