Export teacher applications to gdrive

[megcrenshaw]

Updates the existing export file to use a new gsheet. I followed the process detailed in #39120, which references #32597.

• jira ticket: PLAT-1286

Testing story

Tested end-to-end locally with development secrets configured in Secret Manager. I added the configuration needed in development.yml.erb for local testing––to overwrite values in the Secrets Manager, put in locals.yml.

Things to check:

• The Secrets Manager has the correct applications_2022_2023_gsheet_key for the file in different environments. The key in the development environment is different for testing.
• The cdo-gdrive-export-prod account has write access to the file. Note that if you're testing locally, you need the staging equivalent account for write access to the file, unless you have prod credentials set up in your locals.yml file.

If you are wanting to put credentials into your locals.yml file, it should look something like

gdrive_export_secret:
  type: "service_account"
  project_id: ""
  private_key_id: ""
  private_key: "-----BEGIN PRIVATE KEY-----\n       \n-----END PRIVATE KEY-----\n"
  client_email: ""
  client_id: ""
  auth_uri: ""
  token_uri: ""
  auth_provider_x509_cert_url: ""
  client_x509_cert_url: ""

Let me know if you're wanting to test locally and running into trouble.

Deployment strategy

Follow-up work

Privacy

Security

All secrets are in the AWS Secrets Manager.

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[tim-dot-org]

what is this gdrive_export_secret secret used for?

[megcrenshaw]

It authorizes the gdrive session when running the script so that the account can then go to the file and write to it (if the file gives the account permission)

[davidsbailey]

this is a bit off-topic, but this reminds me that there may be some secret keys in our developer setup process that could be added in this way, so that we don't have to manually add them to locals.yml. properties_encryption_key comes to mind for me:

code-dot-org/locals.yml.default

Lines 53 to 56 in 31a934c

	# Code.org engineers should obtain this from AWS Secrets Manager at:
	# https://console.aws.amazon.com/secretsmanager/home?region=us-east-1#/secret?name=development%2Fcdo%2Fproperties_encryption_key
	# Contributors should ask a Code.org engineer for this if needed.
	#properties_encryption_key: ''

@megcrenshaw , are there any other shared keys which come to mind for you from your recent setup experience?

[megcrenshaw]

Good call. properties_encryption_key: is the only key in my locals file right now, and it's already part of Secrets Manager. Shall I go ahead and add it to the development yml file?

[davidsbailey]

yes please, that would be great!

[davidsbailey]

could please also change the lines in locals.yml.default from

 # Code.org engineers should obtain this from AWS Secrets Manager at: 
 # https://console.aws.amazon.com/secretsmanager/home?region=us-east-1#/secret?name=development%2Fcdo%2Fproperties_encryption_key 

to something like this?

 # Code.org engineers with AWS credentials should get this automatically via AWS Secrets Manager.

the note about Contributors should probably stay.

[megcrenshaw]

Sounds good!

[davidsbailey]

Thanks Meg!