初始化代码时使用 Google Cloud Secrets

Question

I have this code to retrieve the secrets:

import {SecretManagerServiceClient} from "@google-cloud/secret-manager";

const client = new SecretManagerServiceClient();

async function getSecret(secret: String, version = "latest") {
    const projectID = process.env.GOOGLE_CLOUD_PROJECT;
    const [vs] = await client.accessSecretVersion({
        name: `projects/${projectID}/secrets/${secret}/versions/${version}`
    });
    const secretValue = JSON.parse(vs.payload.data.toString());
    return secretValue;
}

export {getSecret};

I would like to replace the process.env.SENTRY_DNS with await getSecrets("SENTRY_DNS") but I can't call a promise ( await ) outside an async function.

Sentry.init({
    dsn: process.env.SENTRY_DNS,
    environment: Config.isBeta ? "Beta" : "Main"
});

function sentryCreateError(message, contexts) {
    Sentry.captureMessage(message, {
        level: "error", // one of 'info', 'warning', or 'error'
        contexts
    });
}

What are the best practices with Google Secrets? Should I be loading the secrets once in a "config" file and then call the values from there? If so, I'm not sure how to do that, do you have an example?

Answer 1

Leaving aside your code example (I don't work with JS anyway), I would think about a few different questions, answers on which may affect the design. For example:

1. Where this code is executed? - compute engine, app engine, cloud run, k8s, cloud function, and so on. Depending on the answer - an approach to store secrets might be different.

Suppose, for example, that is going to be a cloud function. The next question -

2. Would you prefer to store the secret values in a special environment variables, or in the secret manager? The first option is faster, but less secure - as, for instance, everybody, who has access tot he cloud function details in the console, might see those environment variable values.

3. Load secret values into the memory on initialization? Or on every invocation? The first option is faster, but might cause some issues if the secrete values are modified (gradual replacement of old values with new, when some instances are terminated, and new instances are initialized).

The second option may need some additional discussion. It might be possible to get the values asynchronously. In what circumstances it might be useful? I think - only in case your code has something else to do, while waiting for the secret values, which are required to do (probably) the main job of the cloud function. How much can we shave on that? - probably a few milliseconds used on the Secret Manager API call. Any drawbacks? - code complexity, as somebody is to maintain the code in the future. Is that performance gain still overweight? - we probably can return to the item 2 in the list above and think about storing secrets in environment variables in that case.

What about the first option? Again - if the performance is the priority - return back to the item 2 above, otherwise - is the code simplicity and maintainability the priority, and we don't need any asynchronous work here? May be the answer of that question depends on skills, knowledge and a financial budget of your company/team, rather than on the technical preferences.

4. About the "config" file to store the secret values... While it is possible to store data in a pseudo "/tmp" directory (actually in the memory of a cloud function) during the cloud function execution, we should not expect that data to be preserved between cloud function invocations. Thus, we come back to either environment variables (see the item 2 above), or to some other remote place with an API access. I don't know if there are many other services with better latency than the Secret Manager, which can be used as a cache for storing secrets. Suppose we find such services. And now we get the performance vs complexity/maintainability dilemma again...

Some concluding notes. My context, experience, budget, requirements - may be completely different from your case. My assumptions (ie the code is for a cloud function) - can be completely wrong as well... Thus, I would suggest to consider my writing with some criticism, and use ideas which are only relevant for your specific situation.