# Google Secret Manager alternative: Crunu vs GCP > Crunu vs Google Cloud Secret Manager: what CMEK changes and what it doesn't, who decrypts, IAM and Workload Identity for CI, audit logs, rotation and pricing. URL: https://crunu.com/alternatives/google-secret-manager Language: en Updated: 2026-10-30 Google Secret Manager decrypts values for any principal IAM allows, with a key it owns or your CMEK key in Cloud KMS, and suits workloads on Google Cloud. Crunu encrypts on your devices, its server never holds a key, and it serves laptops, servers and CI anywhere. CMEK changes who controls the key, not who decrypts. Google Secret Manager decrypts your secrets inside Google Cloud for whoever IAM lets through; Crunu's server never holds a key that could. Secret Manager is Google Cloud's managed service for secrets and credentials: IAM decides who may read a secret, each version is encrypted with its own data key, and you can bring your own key in Cloud KMS. Crunu is a team vault for environment variables, cloud credentials and API keys, encrypted on your devices and delivered to laptops, servers and CI pipelines in any cloud. One question comes up first: does a customer-managed encryption key, or CMEK, keep Google out? Google's own documentation answers it, and the answer shapes the rest of this comparison: with CMEK you control the key, but Secret Manager still uses it to decrypt on your behalf. > **Note:** We checked every statement about Google Secret Manager against Google Cloud's documentation, gcloud reference and pricing page on October 30, 2026. Sources are listed with this page. If something is out of date, tell us at . ## Who each one fits **Google Secret Manager fits** teams whose workloads run on Google Cloud and can read secrets through IAM and service accounts, such as services on Cloud Run or GKE. It fits teams that want replication across locations, Cloud Audit Logs in their existing setup, a monthly free usage allowance and no extra vendor. **Crunu fits** teams whose secrets travel beyond one cloud project: developers' `.env` files, servers at several providers, CI on GitHub, GitLab or Bitbucket. It fits teams that want the store to be unable to decrypt values, a key per environment, and a precise report of what a departing person received. ## Side by side | | Google Secret Manager | Crunu | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | Where values are decrypted | In the service, transparently, when an authorized principal reads a secret | Only in the browser and the `crunu` agent. The server stores ciphertext and signed documents. | | Who holds the key | By default a key-encryption key owned by Secret Manager; with CMEK, your key in Cloud KMS, used by Secret Manager's service identity | Environment keys sealed to the public keys of people and machines; the account key comes from your password and a Secret Key | | Keys per environment | Each version gets its own data key; separate CMEK keys per secret are your choice | Each environment has its own key, sealed separately to each person and machine allowed to read it | | Who can read | Principals granted access through IAM roles | People and machines that hold the environment key, with roles Editor, Reader, Specific files and Operator | | CI sign-in | Workload Identity Federation lets GitHub Actions, GitLab and other pipelines use their OIDC tokens | Service tokens bound by OIDC to repository, branch and deployment environment on GitHub Actions, GitLab CI, Bitbucket Pipelines or any issuer | | Rotation | Scheduled notifications to Pub/Sub; creating the new value is up to you | Rotates its own encryption keys. Values at providers are reissued by hand, from a checklist. | | Where it runs | A managed Google Cloud service | Crunu cloud at app.crunu.com; on the Enterprise plan, also your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run | | Replication and sync | Replicates secrets across Google Cloud locations; pushing to other platforms is not documented | Not built in. A CI step can push values with `crunu run`. | | Audit | Cloud Audit Logs: Admin Activity logs, and Data Access logs for reads, which are off by default | Hash-chained audit log, 365 days by default and extendable, with JSONL export. Values never reach it. | | Sharing with outsiders | Access is granted through IAM; no share-link feature is documented | Share links to selected files with an expiry, a view limit and a password; the key stays in the link after `#` | | Kubernetes and identity | Secret Manager add-on for GKE; workforce sign-in through Workforce Identity Federation | Not available | | Pricing model | Monthly free usage for active secret versions and access operations, then billed by use | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan | ## What CMEK changes, and what it doesn't *Figure: Diagram of who can decrypt Google Cloud Secret Manager values, split into your side and the provider side. On your side, your team’s devices, your machines, and CI runners can decrypt. On the provider side, the Google Cloud Secret Manager service holds the key and can decrypt values too. Cloud IAM principals with decrypt permission can decrypt as well.* Secret Manager encrypts each secret version with its own data encryption key. By default, that data key is wrapped by a key-encryption key owned by the Secret Manager service, and the data is decrypted automatically and transparently when an authorized user reads it. With CMEK, the key-encryption key becomes a symmetric key you manage in Cloud KMS. Google's documentation is explicit about what happens next: the service identity for Secret Manager, rather than the caller, encrypts and decrypts secrets, and Secret Manager calls Cloud KMS every time it performs a cryptographic operation. You gain real control. Disable or destroy the key and the data can no longer be decrypted; a destroyed key makes it unrecoverable. What you do not gain is a store that cannot read your values. Decryption still happens inside Google Cloud, for any principal that IAM allows. Crunu moves decryption off the server entirely. Values are encrypted before they leave your device and decrypted only where an environment key lives: a teammate's browser, an enrolled server running `crunu daemon`, or a CI runner with a service token. The server holds ciphertext, public keys and signed access lists, and it never has a key to decrypt a value. A compromised server cannot add itself as a reader, because the access lists are signed by an administrator. ### Seeing who read what Reads of secret values are Data Access audit logs, and Google Cloud keeps those disabled by default for nearly all services, so you need to turn them on before you can answer who accessed a secret. Crunu records every fetch by person, version, time and address from the start. When someone leaves, the [member removal flow](https://crunu.com/features/offboarding) rotates the keys of every environment they could read and lists the values to reissue at providers. Values they already saw stay valid until you reissue them, as the [limitations page](https://crunu.com/security/limitations) explains. ## Where Google Secret Manager is stronger - **Native IAM.** Workloads on Google Cloud read secrets through service accounts, with nothing stored on the machine. Crunu machines enroll with a code and keep a key of their own. - **Your own key, with a kill switch.** CMEK in Cloud KMS lets you disable or destroy the key that protects your secrets. Crunu's keys come from your password and Secret Key, not from a cloud KMS. - **Platform features.** Replication across locations, a GKE add-on that mounts secrets as volumes, rotation notifications and Workforce Identity Federation. Crunu has no Kubernetes or SSO support. - **Free usage and no new vendor.** A monthly free allowance inside an account you already have. Crunu is a new vendor in early access, with no external audit published. ## Moving from Google Secret Manager to Crunu > **Note:** Crunu has no importer for Google Secret Manager. You read each secret with `gcloud` on a trusted computer, write the values into `.env` files and drag the files into Crunu. 1. [Create an account](https://crunu.com/signup) and save your Emergency Kit. 2. Create a project for each application and an environment for each stage, for example `payments-api` with `development`, `staging` and `production`. 3. On a trusted computer, run `gcloud secrets versions access latest --secret=STRIPE_SECRET_KEY` for each secret an application uses, and write each result as a `KEY=VALUE` line in a `.env` file. 4. Drag the files into the matching environments, then delete the plaintext copies. 5. Start programs with `crunu run --env payments-api/production -- npm start`, and enroll their servers as machines. 6. Give pipelines service tokens with OIDC binding, in place of their Workload Identity Federation access to Secret Manager. Replication, rotation notifications and IAM-based reads from Google Cloud services have no equivalent in Crunu. You can keep Secret Manager for workloads inside Google Cloud and move only the team's own environments. If you host your own Crunu server on Cloud Run, on the Enterprise plan, its deploy script keeps the server's configuration secrets in Secret Manager; your team's values stay ciphertext. > **Warning:** The files from step 3 hold plaintext secrets. Keep them out of Git and synced folders, and delete them after the import. ## Other Google Secret Manager alternatives The other two big clouds follow the same model. [AWS Secrets Manager](https://crunu.com/alternatives/aws-secrets-manager) decrypts each secret with AWS KMS before returning it, and [Azure Key Vault](https://crunu.com/alternatives/azure-key-vault) decrypts secrets automatically when you read them. Several tools push values into Google Secret Manager from one central place: [Doppler](https://crunu.com/alternatives/doppler) syncs to AWS, GCP and Azure stores, and [Keeper Secrets Manager](https://crunu.com/alternatives/keeper-secrets-manager) has a one-way sync into all three. [HashiCorp Vault](https://crunu.com/alternatives/hashicorp-vault) is the self-hosted option for teams that want one platform with dynamic credentials across clouds. If the reason you are looking is who can decrypt, tools that decrypt on the client are the other route: [Phase](https://crunu.com/alternatives/phase), [Bitwarden Secrets Manager](https://crunu.com/alternatives/bitwarden-secrets-manager) and Crunu. The article [customer-managed keys: who decrypts?](https://crunu.com/blog/customer-managed-keys-who-decrypts) walks through CMEK and its equivalents at AWS and Azure. ## FAQ ### Is Crunu an alternative to Google Secret Manager? Yes, for team secrets that live on laptops, servers and CI pipelines, especially outside Google Cloud. For workloads inside Google Cloud that read secrets through IAM and service accounts, Secret Manager remains the simpler fit, and you can use both. ### How do I move from Google Secret Manager to Crunu? Read each secret with `gcloud secrets versions access latest --secret=NAME` on a trusted computer, write the values as `KEY=VALUE` lines into a `.env` file, drag it into a Crunu environment and delete the plaintext copy. Then start programs with `crunu run` and give pipelines OIDC-bound service tokens. ### Does CMEK stop Google from decrypting my secrets? No. With CMEK, the key-encryption key is yours in Cloud KMS, but Google's documentation says the Secret Manager service identity, not the caller, encrypts and decrypts secrets. You can disable or destroy the key, which makes the data unreadable for everyone. ### Are reads of my secrets logged? Only if you enable them. Accessing a secret version produces a Data Access audit log, and Google Cloud disables Data Access audit logs by default for nearly all services. Crunu records every fetch by person, version, time and address. ### Can I run Crunu on Google Cloud? Yes, on the Enterprise plan, under a signed agreement. A self-hosted Crunu server can run on Google Cloud Run with Postgres, and it can move to Docker, Cloudflare Workers or Vercel with one archive that holds no plaintext values. See [self-hosting](https://crunu.com/self-hosting). ## Sources - [Google Cloud Secret Manager: Encryption](https://cloud.google.com/secret-manager/docs/encryption) (accessed 2026-10-30) - [Google Cloud Secret Manager: Customer-managed encryption keys](https://docs.cloud.google.com/secret-manager/docs/cmek) (accessed 2026-10-30) - [Google Cloud Secret Manager: Overview](https://cloud.google.com/secret-manager/docs/overview) (accessed 2026-10-30) - [Google Cloud Secret Manager: Access control with IAM](https://cloud.google.com/secret-manager/docs/access-control) (accessed 2026-10-30) - [Google Cloud Secret Manager: Audit logging](https://docs.cloud.google.com/secret-manager/docs/audit-logging) (accessed 2026-10-30) - [Google Cloud Logging: Enable Data Access audit logs](https://docs.cloud.google.com/logging/docs/audit/configure-data-access) (accessed 2026-10-30) - [Google Cloud Secret Manager: Rotation schedules](https://cloud.google.com/secret-manager/docs/secret-rotation) (accessed 2026-10-30) - [Google Cloud Secret Manager: Add-on for GKE](https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component) (accessed 2026-10-30) - [Google Cloud IAM: Workload Identity Federation with deployment pipelines](https://cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines) (accessed 2026-10-30) - [Google Cloud IAM: Workforce Identity Federation](https://cloud.google.com/iam/docs/workforce-identity-federation) (accessed 2026-10-30) - [gcloud reference: secrets versions access](https://docs.cloud.google.com/sdk/gcloud/reference/secrets/versions/access) (accessed 2026-10-30) - [Google Cloud Secret Manager pricing](https://cloud.google.com/secret-manager/pricing) (accessed 2026-10-30) - [AWS Secrets Manager: Secret encryption and decryption](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) (accessed 2026-10-30) - [Azure Key Vault: About secrets](https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets) (accessed 2026-10-30) - [Doppler integrations](https://docs.doppler.com/docs/integrations) (accessed 2026-10-30) - [Keeper docs: Sync command](https://docs.keeper.io/en/keeperpam/secrets-manager/secrets-manager-command-line-interface/sync-command) (accessed 2026-10-30) - [Phase security](https://phase.dev/security/) (accessed 2026-10-30) - [Bitwarden Help: Secrets Manager overview](https://bitwarden.com/help/secrets-manager-overview/) (accessed 2026-10-30)