feat: Add support for secrets manager environment variables

[christophersjchow]

Add support for setting environment variables that pull from Secrets Manager.

I basically copied the pattern that environment variables are currently being set so would appreciate anything I've missed.

[pgrzesik]

Hello @christophersjchow - could you please link to the documetation that shows how that secrets data should be passed? It would help me better understand how we could shape it to be convenient for the plugin users

[christophersjchow]

@pgrzesik The resource for the Cloud Function is described here in the REST API reference: https://cloud.google.com/functions/docs/reference/rest/v1/projects.locations.functions

In there there's a field:

"secretEnvironmentVariables": [
    {
      object ([SecretEnvVar]
    }
  ],

Which links to the SecretsEnvVar doc here: https://cloud.google.com/functions/docs/reference/rest/v1/projects.locations.functions#SecretEnvVar

That describes the object structure as:

{
  "key": string,
  "projectId": string,
  "secret": string,
  "version": string
}

I tested this locally by linking this package into one of our projects and successfully deployed through Deployment manager.

[christophersjchow]

Any chance you could approve me for GitHub Actions too so CI will run?

[pgrzesik]

Thanks a lot for the update @christophersjchow - I won't be able to look at it more closely this week, but I will find some time for it at the beginning of the next week.

[christophersjchow]

Sorry for the delay @christophersjchow - I was swamped with other priorities - it looks good in general, but I'm afraid we need to figure out the best representation of this setting in serverless configuration - could you propose how it could look like?

@pgrzesik The PR simply passes it through to the Deployment manager config. Here is an example as per the docs I've added here: https://github.com/serverless/serverless/pull/10660

I think leaving the options the same as what Deployment Manager would expect is reasonable here, as this relies heavily on those specific options. The ID of the secret, version of the secret and the environment variable key to set are all compulsory and I don't think it's helpful to invent a syntax we would have to parse to set these values (like the example @sambauers suggested above).

In the current form, it would be possible to define at most a single secret variable - how do you think it would be best to expose these settings in serverless configuration?

The config on the serverless side allows for an array of secrets to be set. From the docs PR:

provider:
  secrets:
  - key: 'API_KEY'
    secret: 'secret-id'
    version: 'latest'
    projectId: 'project-id' # Optional, defaults to function project

[christophersjchow]

@pgrzesik I can see that there's a call for maintainers for this plugin. I'd be willing to help out.

[R3VoLuT1OneR]

@pgrzesik This future is super helpful. Currently, I can't set secret env variable out of the scope of the serverless deployment. Want to set it one time in a secure way.

Environment variables that are set manually are overridden by the next deployment.

The implementation looks good, let's merge and release it :)