0

I am attempting to use the Google Admin SDK to read user data within cloud functions. I am developing this on a local machine then running a Google Build that deploys the cloud function. How can I initialize the Admin SDK in python using a key (or a set of keys)? Ideally, I'd like to keep the secret key locally under .env (not in source control), then use IAM's Cryptographic Keychain to generate an encrypted key that can be kept in source control. However, I do not see how I can initialize the Python Admin SDK with just a series of keys. How is this achievable?

user1222324562
  • 965
  • 2
  • 9
  • 24
  • 2
    Don't use "keys" in files at all. Use the service account credentials for Cloud Functions. https://cloud.google.com/functions/docs/concepts/iam https://cloud.google.com/iam/docs/understanding-service-accounts – John Hanley Jun 07 '19 at 04:24
  • @JohnHanley Thank you for this tip. How do you suggest developing and testing locally before deploying? My Pipeline right now is to develop locally, on commits trigger a Google Build, then have that deploy Google Cloud Functions. – user1222324562 Jun 07 '19 at 22:23
  • 1
    For local development, use a service account and have a "debug" code block that loads the credentials from the JSON key file. For your application, I would use Google Cloud Run. Then you can switch to containers and make your development and deployment process easier. Cloud Functions is also containers, but you don't have the flexibility that Cloud Run offers. – John Hanley Jun 07 '19 at 22:39
  • @JohnHanley There would need to be a service account for the Admin Directory API right? I do not see one here https://cloud.google.com/iam/docs/understanding-roles – user1222324562 Jun 08 '19 at 00:37
  • 1
    Search for G Suite Domain Wide Delegation. Follow that article to create the service account and authorization. – John Hanley Jun 08 '19 at 00:42
  • @JohnHanley I saw that but (as the example shows) I would need to provide a file `ServiceAccountCredentials.from_p12_keyfile(...` – user1222324562 Jun 08 '19 at 01:04
  • 1
    You are looking at an old article. P12 has been deprecated. – John Hanley Jun 08 '19 at 01:15
  • @JohnHanley https://developers.google.com/admin-sdk/reports/v1/guides/delegation This is what I'm using, it was updated January 2019. Is there a more updated article for this? – user1222324562 Jun 09 '19 at 16:06
  • 1
    Yes, that is the right article, but it needs to be updated. For Python change `from_p12_keyfile()` to `from_service_account_json()`. The P12 format is deprecated and the JSON format is now preferred by most GCP libraries. I wrote several articles on my website about services accounts, P12 and JSON formats, etc. https://www.jhanley.com – John Hanley Jun 09 '19 at 17:09
  • @JohnHanley Ah, no I understand that it's better practice to use a `json` files from that article. My confusion was how I can keep my protected files out of source control but still have some way of authenticating a Cloud Run service to use the Google Admin SDK. – user1222324562 Jun 10 '19 at 00:50
  • 1
    This week, I will be releasing an article on my website that covers sending an email, including G Suite Domain Wide Delegation using Cloud Run. – John Hanley Jun 10 '19 at 01:19
  • 1
    I previously wrote an article on how to store encrypted files on Cloud Storage and access from Cloud Run. In this article, I do NOT use or store a JSON key file anywhere. Everything is done using a service account email address only. This is the most secure method as you do not download the key file from Google - nothing to lose or get stolen. https://www.jhanley.com/google-cloud-run-identity/ – John Hanley Jun 10 '19 at 01:20
  • @JohnHanley You have been very helpful, thank you for your patience in helping me understand this platform – user1222324562 Jun 10 '19 at 02:20
  • @JohnHanley What is the best practice for sharing a repo for development with others? Is it okay to keep any `.enc` file in the repo or should they download it directly from Google Storage before working? – user1222324562 Jun 13 '19 at 18:06
  • Is this private in your company or a public project you are sharing? – John Hanley Jun 13 '19 at 18:44
  • 1
    For a private development group, you can separate secret creation from developers. Note: The developers can still read the secrets because they are decrypting them in software. It is the management/rotation that is separated. The management/DevOps team creates an encrypted secrets file and puts it on Cloud Storage. The development team just downloads and uses the file. They do not have to worry about permissions, production key rotation, etc. as the DevOps team does that for them. – John Hanley Jun 13 '19 at 18:48
  • 1
    When the software is transitioned to the next phase (testing/deployment/etc) the DevOps team can rotate and delete the developer credentials just by replacing the encrypted secrets file. – John Hanley Jun 13 '19 at 18:48

0 Answers0