Google Secret Manager: Secure Access via Apps Script

Introduction
In modern cloud‑first environments, protecting API keys, passwords, and other confidential data is a top priority. Google Secret Manager provides a centralized, auditable vault for such secrets, while Google Apps Script offers a lightweight, server‑less way to automate G Suite and Google Cloud tasks. This guide shows you, step by step, how to bridge the two services so your Apps Script projects can retrieve secrets securely, without hard‑coding credentials. We’ll cover the necessary IAM configuration, the exact Apps Script code needed to call the Secret Manager API, error‑handling techniques, and a practical example that you can adapt to your own workflows. By the end, you’ll be able to manage sensitive data responsibly and keep your scripts both functional and compliant.

Understanding Google Secret Manager
Google Secret Manager stores encrypted secret payloads in a regional or multi‑regional location. Each secret can have multiple versions, and access is controlled via Cloud IAM roles such as Secret Manager Secret Accessor. Knowing the structure—projects/<PROJECT_ID>/secrets/<SECRET_ID>/versions/<VERSION>—is essential because Apps Script must reference this exact path when requesting a secret. The service also logs every access event, giving you auditability and the ability to rotate secrets without changing application code.

Setting Up IAM and Service Accounts for Apps Script
1. Create a dedicated service account in the Google Cloud console for your Apps Script project.
2. Grant the role roles/secretmanager.secretAccessor on the desired secret (or on the whole project) to that service account.
3. Enable the Secret Manager API for the project if it isn’t already active.
4. In Apps Script, open Resources → Cloud Platform project and link the script to the same GCP project that hosts the service account.
5. Deploy the script as an executable (e.g., a Web App) and set “Execute the app as” to “Me (your email)” or “User accessing the web app,” depending on the required scope. This ensures the script runs with the service account’s permissions.

Fetching Secrets with Apps Script
The Secret Manager API is a standard REST endpoint, so you can call it using Apps Script’s UrlFetchApp. Below is a reusable function that returns the clear‑text payload of a secret version:

• Code snippet:

  function getSecret(projectId, secretId, version = 'latest') {
    const url = `https://secretmanager.googleapis.com/v1/projects/${projectId}/secrets/${secretId}/versions/${version}:access`;
    const options = {
      method: 'GET',
      muteHttpExceptions: true,
      headers: {
        Authorization: 'Bearer ' + ScriptApp.getOAuthToken()
      }
    };
    const response = UrlFetchApp.fetch(url, options);
    if (response.getResponseCode() !== 200) {
      throw new Error('Unable to fetch secret: ' + response.getContentText());
    }
    const payload = JSON.parse(response.getContentText());
    return Utilities.newBlob(Utilities.base64Decode(payload.payload.data)).getDataAsString();
  }
  

• Usage example:

  const apiKey = getSecret('my-gcp-project', 'my-api-key');
  Logger.log('Retrieved API key: ' + apiKey);
  

This function automatically uses the OAuth token of the executing Apps Script, which inherits the service account’s Secret Manager permissions.

Best Practices and Error Handling

• Version control: Always request a specific version (e.g., 1) in production to avoid accidental rotation issues.
• Cache locally: For high‑frequency calls, store the secret in CacheService for a short period (e.g., 5 minutes) to reduce API quota consumption.
• Graceful fallback: Wrap the fetch call in a try/catch block and provide a meaningful error message or fallback logic.
• Audit logging: Enable Cloud Audit Logs for Secret Manager to monitor who accessed which secret and when.
• Least‑privilege principle: Assign the accessor role only to the specific secret(s) required, not to the whole project.

Putting It All Together – Real‑World Example
Imagine a Google Sheet that pulls data from an external API. Instead of storing the API token in a cell, you can retrieve it securely at runtime:

• Step 1: Store the token in Secret Manager as external‑api‑token.
• Step 2: Add the accessor role to the Apps Script service account.
• Step 3: Use the getSecret function inside a custom menu item:

  function onOpen() {
    SpreadsheetApp.getUi()
      .createMenu('External API')
      .addItem('Refresh Data', 'refreshData')
      .addToUi();
  }
  
  function refreshData() {
    const token = getSecret('my-gcp-project', 'external-api-token');
    const response = UrlFetchApp.fetch('https://api.example.com/data', {
      headers: { Authorization: 'Bearer ' + token }
    });
    const data = JSON.parse(response.getContentText());
    // Process and write data to the sheet...
  }
  

• Step 4: Deploy the script, test the menu, and verify that the token never appears in the script editor or sheet cells.

By following these steps, you keep credentials out of source code, benefit from automatic rotation, and maintain a clear audit trail—all while leveraging the simplicity of Apps Script.

Conclusion
This guide has walked you through the entire lifecycle of accessing Google Secret Manager secrets from Apps Script: understanding the vault, configuring IAM and service accounts, writing robust fetch code, applying security‑focused best practices, and implementing a practical use case. By separating secret storage from application logic, you reduce the risk of accidental exposure and simplify credential rotation. Remember to grant only the necessary permissions, cache responsibly, and monitor audit logs to stay ahead of potential issues. With these techniques in place, your Apps Script projects can handle passwords, API keys, and other sensitive data safely, letting you focus on building value‑adding automation rather than worrying about security loopholes.